C++ continues to be the dumping ground of paradigms and language features. This proposal just aims to add even more to an overloaded language.
C++ programmers mocked languages for being dynamically typed then they introduced
auto, they mocked JS for callback hell and introduced lambdas, they mocked Rust devs for being lowskill C++ devs who can’t manage their own memory and now they are admitting they can’t manage it themselves either.It’s going to be come like the x86 instruction set or windows that is backwards compatible with stuff from 30years ago just accumulating cruft, unable to let go.
auto isn’t dynamic typing it’s just type inference. It still has a fixed type you just don’t have to write it. Like var in C#.
Lambdas are just a way of defining methods in place. It has nothing to do with callbacks.
But you’re spot on for memory safety. Managing it yourself is risky and if it can be managed at zero cost it seems stupid not to.
auto isn’t dynamic typing it’s just type inference.
I’m aware, but one of the big arguments I’ve heard about dynamic typing is “I don’t know which type it has when I read the code”. Well, auto looks just like var in that regard.
Lambdas are just a way of defining methods in place. It has nothing to do with callbacks.
Callback definition from wikipedia:
In computer programming, a callback is a function that is stored as data (a reference) and designed to be called by another function – often back to the original abstraction layer.
This is exactly what lambdas are often used for in C++.
Well, auto looks just like var in that regard.
It really isn’t. Neither in C# nor in Java. They are just syntactic sugar to avoid redundant type specifications. I mean things like
Foo foo = new Foo();. Who gets confused with that?Why do you think IDEs are able to tell which type a variable is?
Even C# takes a step further and allows developer to omit the constructor with their target-typed new expressions. No one is whining about dynamic types just because the language let’s you instantiate an object with
Foo foo = new();.The problem with dynamic typing is you can’t always figure out what the type is even with investigation as it can be lots of things based on what is passed or returned. It also allows incorrect values to be passed.
People will indeed make that readability argument but if the type is not obvious and important to understanding the code then it likely shouldn’t be used there.
Keyword being “shouldn’t”. C++ doesn’t care about that, it just hands you the loaded gun.
I wouldn’t call bad readability a loaded gun really. Your dev tools will hopefully make it pretty easy to learn the type. It should be a minor inconvenience at best.
I wouldn’t call bad readability a loaded gun really.
Bad readability is a problem cause by the developer, not the language. Anyone can crank out unreadable symbol soup in any language, if that’s what they want/can deliver.
Blaming the programming language for the programmer’s incompetence is very telling, so telling there’s even a saying: A bad workman always blames his tools.
C++ continues to be the dumping ground of paradigms and language features. This proposal just aims to add even more to an overloaded language.
I think you could not be more wrong even if you tried, and you clearly did not even read the proposal you’re commenting on.
This proposal aims to basically create an entirely different programming language aimed at being easy to integrate in extsting codebases. The language just so happens to share some syntax with C++, but you definitely can’t compile it with a C++ compiler because it introduces a series of backwards incompatible changes.
It’s also absurd how you complain about introducing new features. Can you point out any language that is not absolutely dead that is not introducing new features with each release?
C++ programmers mocked languages for being dynamically typed then they introduced auto (…)
I’m sorry, you are clearly confused. The
autokeyword is not “dynamically typed”. It is called “auto” because it does automatic type deduction. It is syntactic sugar to avoid having to explicitly specify the type name in places the compiler knows it already. Do you understand what this means?Your comment sounds like trolling, frankly.
Haven’t read through this, but this sounds like what C++ is to C. I’m not sure adding more complexity and features to an already complex language is the right way forward. What is needed is a language that cuts down all the burden that has accumulated in C++ over 3 decades.
Something like Zig sounds like the better path forward to me. A completely new language from scratch with cross interoperability to C++. I’m surprised it’s not mentioned even once in the page.
I went for a blood test two days ago.
The girls came back sprinting with some papers, asking me how it was possible???
I asked calmly what was going on, right? That’s when she said she never saw, in her entire life, such beautiful, elegant, fast and clean blood!
I was like: “darling, that’s because Zig is flowing in my veins, I just can’t stop using it”…
That being said, I totally agree with you.
It’s very hard for “Safe C++” to exist when integer overflow is UB. Rust also gets it wrong, though not quite in the same way. Ada gets it right.
By Ada getting it right, I assume you mean throwing an exception on any overflow? (Apparently this behavior was optional in older versions of GNAT.) Why is Ada’s preferable to Rust’s?
In Rust, integer overflow panics by default in debug mode but wraps silently in release mode; but, optionally, you can specify wrapping, checked (panicking), or unchecked behavior for a specific operation, so that optimization level doesn’t affect the behavior. This makes sense to me; the unoptimized version is the same as Ada, and the optimized version is not UB, but you can control the behavior explicitly when necessary.
In Ada, the overflow behaviour is determined by the type signature. You can also sometimes use SPARK to statically guarantee the absence of overflow in a program. In Rust, as I understand it, you can control the overflow behaviour of a particular arithmetic operation by wrapping a function or macro call around it, but that is ugly and too easy to omit.
For ordinary integers, an arithmetic overflow is similar to an OOB array reference and should be trapped, though you might sometimes choose to disable the trap for better performance, similar to how you might disable an array subscript OOB check. Wraparound for ordinary integers is simply incorrect. You might want it for modular arithmetic and that is fine, but in Ada you get that by specifying it in the type declaration. Also in Ada, you can specify the min and max bounds, or the modulus in the case of modular arithmetic. For example, you could have a “day of week as integer” ranging from 1 to 7, that traps on overflow.
GNAT imho made an error of judgment by disabling the overflow check by default, but at least you can turn it back on.
The RISC-V architecture designers made a harder to fix error by making everything wraparound, with no flags or traps to catch unintentional overflow, so you have to generate extra code for every arithmetic op.
It sounds like you’re talking about dependent typing, then, at least for integers? That’s certainly a feature Rust lacks that seems like it would be nice, though I understand it’s quite complicated to implement and would probably make Rust compile times much slower.
For ordinary integers, an arithmetic overflow is similar to an OOB array reference and should be trapped, though you might sometimes choose to disable the trap for better performance, similar to how you might disable an array subscript OOB check.
That’s exactly what I described above. By default, trapping on overflow/underflow is enabled for debug builds and disabled for release builds. As I said, I think this is a sensible behavior. But in addition to per-operation explicit handling, you can explicitly turn global trapping behavior trapping on or off in your build profile, though.
In Ada? No dependent types, you just declare how to handle overflow, like declaring int16 vs int32 or similar. Dependent types means something entirely different and they are checked at compile time. SPARK uses something more like Hoare logic. Regular Ada uses runtime checks.
Whatever you want to call them, my point is that most languages, including Rust, don’t have a way to define new integer types that are constrained by user-provided bounds.
Dependent types, as far as I’m aware, aren’t defined in terms of “compile time” versus “run time”; they’re just types that depend on a value. It seems to me that constraining an integer type to a specific range of values is a clear example of that, but I’m not a type theory expert.
Dependent types only make sense in the context of static typing, i.e. compile time. In a dependently typed language, if you have a term with type {1,2,3,4,5,6,7} and the program typechecks at compile time, you are guaranteed that there is no execution path through which that term takes on a value outside that set. You may need to supply a complicated proof to help the compiler.
In Ada you can define an integer type of range 1…7 and it is no big deal. There is no static guarantee like dependent types would give you. Instead, the runtime throws an exception if an out-of-range number gets sent there. It’s simply a matter of the compiler generating extra code to do these checks.
There is a separate Ada-related tool called SPARK that can let you statically guarantee that the value stays in range. The verification method doesn’t involve dependent types and you’d use the tool somewhat differently, but the end result is similar.
For what it’s worth, Ada and Spark are listed separately in the Wiki article on dependent typing. Again, though, I’m not a language expert.
It’s very hard for “Safe C++” to exist when integer overflow is UB.
You could simply state you did not read the article and decided to comment out of ignorance.
If you spent one minute skimming through the article, you would have stumbled upon the section on undefined behavior. Instead, you opted to post ignorant drivel.
This is cool in theory but this is yet another competing standard of static analysis.
We got clang-tidy, CPPAnalyser, etc… etc…
this is yet another competing standard of static analysis.
No, it isn’t.
Those are linters. They might or might not discover problematic use of unsafe language features lurking in existing code.
This proposal is a new iteration of the language and standard library. It would provide safe language features for preventing such problems existing in the first place.
Right now, we have to compile the compiler for this ourselves. Pardon my skepticism; I’m not sure this is mature enough.
Edit: I’m talking about the project not the idea. Sean Baxter has shown up everywhere for awhile talking about this. I think his idea has a ton of maturity. I don’t know that the project itself has enough maturity to mainline yet.
That’s fair. I think the last word in the URL does a good job of representing the implementation’s claimed level of maturity:
draft
:)
You said
This proposal is a new iteration of the language and standard library. It would provide safe language features for preventing such problems existing in the first place.
Either it’s a draft or it’s a new iteration of the language. Can’t be both.
Either it’s a draft or it’s a new iteration of the language. Can’t be both.
It’s a draft of a proposal for a new iteration. Is that so difficult to understand?
Annnnnnnnnnnnd we’re done. Good luck! I highly recommend you take some time to understand how draft can mean more in the technical space. It might help you in the future when you are discussing things like drafts, specifications, and proposals.
I think it’s pretty clear that IETF drafts are not what author meant when he wrote draft, and I’m pretty sure the IETF doesn’t have much to do with C++ standards.
Are you under the impression that there is no other sense of the word?
It might help you in the future when you are discussing things like drafts, specifications, and proposals.
As it turns out, I have done more than a little of that. Thankfully, I don’t usually see such condescending remarks in the process, nor such insistence on misunderstanding. Good luck to you, too.
He never said it was an Internet Draft. Try actually reading. It might help you in the future when you are discussing things.
This is “It’s just a THEORY” but for programmers
It’s a concept of a plan
I am also curious how much of those “%70 of the vulnerabilities” would be detected by tools like valgrind, CPPcheck etc (either directly in the former case or indirectly in the latter). If a major part, then the main problem is people not incentivized to / not having enough time to use these tools.
Valgrind is pretty crazy to find bugs and memory leaks !
Where does the document number come from? I can’t find anything about the SG or linked orgs that defines a sequence.
Extend C++ for safety
I stopped reading after this. Why do you think C++ is unsafe in the first place? Someone decided ro extend it, and now you cannot even read an error message without finishing an university course on lambda calculus first.
