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.
This is cool in theory but this is yet another competing standard of static analysis.
We got clang-tidy, CPPAnalyser, etc… etc…
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 !
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.
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’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.
Where does the document number come from? I can’t find anything about the SG or linked orgs that defines a sequence.
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++.
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.
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.
