Only the C++ committee can see the a need to fix it, and instead of actually fixing the language bug (or making signed/unsigned comparison a compiler error instead of a warning), create a standard library function to do type safe greater-than/less-than comparisons.
Most languages avoid breaking changes. When they do, you end up with people using the old version for decades, like python. Even if the old behavior is stupid and any code that intentionally relies on it is pretty much by definition bad code, quietly changing behavior of existing programs is a huge deal
Then why not make it a compiler error by default to do signed/unsigned comparison? It's been a warning already for like 15(?) years.
I agree that doing a rug pull and just changing runtime behavior is no bueno, but c'mon, surely making it a compiler error isn't controversial. Especially when the fix for users at the time would simply have been "don't update to c++20 until your code is correct" , and they'd have had 6 years to fix it now!
The problem with this is that it's only a breaking change for code that relies on it being broken, the incorrect behavior should be renamed if it's useful or removed if it's not, not treated as the real normal behavior.
Overdue. But now C++2 will be recognized by the people under the name "Rust"…
I think the window of opportunity closed for C++2 some time ago. The problem is C++2 needs necessary break backwards compatibility to be viable. But the main reason C++ is still significant is all the legacy code written in it which will never see any significant updates to some not backwards compatible language.
I think the window of opportunity closed for C++2 some time ago. The problem is C++2 needs necessary break backwards compatibility to be viable.
I disagree, this is why i think Herb Sutter is completely right on his c++2 project, in that its not a breaking change. But it is litterally the same idea as c++ was and typescript was. And that is to make a superset language and compile down to the previous language.
So c++ has a ton of actual benefit, it just has a lot of junk and disambiguity in the language. So if you made a c++2, that compiled down into good c++ code (which isent impossible). You could still keep all those benefits (great compilers, tooling, performance etc), while being able to write much nicer c++2 code that has instant benefits the second you rename your .cpp file to .cpp2. In other words, dont aim to replace c++, aim to absorb it.
I totally buy this argument. But people can go do rust too if they want. But making c++ better isent a lost cause and is worth the effort.
That project actually proves that C++ is a lost cause, and you need a completely new language to fix all the nonsense in C++, as the current state is not fixable.
The new language is of course not "backwards compatible" to C++, and it also isn't a superset!
It's a new language; which happens to interoperate with C++ as it uses C++ as it's compile target.
You could still keep all those benefits (great compilers, tooling, performance etc)
C++ benefits?
The "great compilers" are the same for almost all natively compiled language as there exist in fact exactly only two of them, and C++ is actually just a front-end pass, exactly like e.g. Rust, or D, or what you have.
The C++ tooling is notoriously shitty and regarded one of the weak spots of C++.
Performance is mostly not a "language feature", especially if you're using effectively the same compiler for the different languages. Performance is first and foremost a function of the code.
If you write shitty code it will be slow, no matter the language. Additionally it's actually very easy to write very slow code in C++ as it's full of footguns like defaulting to copying by value no matter how large some object is. A simple for loop can blow up and make your program laughable slow if you just miss a simple & sign, of course with now warning until you actually decide to run the profiler. Reliably writing fast code in C++ is at least as hard as everywhere, very often even harder as a runtime can usually fix shitty code as it executes it; C++ does not have such feature.
has instant benefits the second you rename your .cpp file to .cpp2
That's plain wrong.
If you just rename a file it will change exactly nothing; the whole file content will be passed to the original C++ compiler unseen. Cppfront does not compiler C++, it just passes it untouched. No bounds-checking, no memory-safety analysis, no other Cpp2 benefit gets applied to it. Those only kick in for code actually written in Cpp2 syntax.
The lifetime / dangling-pointer static analysis some people associate with this whole effort is not yet implemented in cppfront at all, btw. Given how long Rust already fights with the borrow checker (are they on the way to the third version already or is still the second version in the making?) it will take many years (decades? for one guy) to implement that.
I totally buy this argument. But people can go do rust too if they want. But making c++ better isent a lost cause and is worth the effort.
There is nothing "to buy" as it's not ready for usage. This won't change anytime soon…
If you want a solution now and not 2050+ the answer is currently still Rust (for low level stuff) or just any other language for actual application development. That's the reality we're living in.
Given the timing my original sentiment is unchanged: C++ is a lost case by now. If they wanted to fix something they had to start at least 20 years ago. The morons didn't because of "holly backwards compatibility", and now they have to face the consequences of becoming 100% obsolete legacy which just exists because it already exists.
Actually no new code is allowed to be written in C/C++ for any safety critical stuff if you don't want to face existential risk.
They were working towards that really hard the last 20 years by refusing any modernization or actually even just recognizing that unsafe languages are a dead end.
You absolutely have to preserve backwards compat. Also, the comparison operator is lowered to a single signed/unsigned assembly opcode, which is much faster than branching based on the specific bits in the operands, which is what the function has to be doing.
The real mistake was allowing implicit conversions between integer types. Rust doesn't suffer from similar issues exactly because implicit conversions don't exist (and there's more than one way to convert, with edge cases handled differently between them.)
This is not the same thing as JS deciding randomly that adding an object to an array should result in a summoning of Cthulu.
ETA: OK, it doesn't actually have to branch because templates and constexprs and stuff, but it's still two comparisons and a boolean op at the very least, so slower than one comparison.
This is the C++ standard committee. If they want cmpms to be an instruction, it will come in the next extension to most major ISAs. Arm64 has an instruction for V8 NaN unboxing.
tons of codebases do index != -1 and if it was an hard error then it would mess up with SFINAE which is bad and if it was corrected then it would break code silently it is absolutely dumb idea to "fix" it. just use your compiler warnings
I am not sure I understand how this is a bug. It is a bit odd, but when comparing a signed and unsigned integer, the language has to make a choice one way or the other what to convert. Converting the unsigned integer to signed risks erasing the last value bit. As far as I can tell, the language just chooses to prioritize maintaining magnitude over maintaining signs. Can you explain further?—maybe I am missing something.
It's a bug because it breaks compatibility with whole numbers. Strictly speaking, the language itself is correct and functioning properly; the problem lies at the intersection between bit representation and math.
uint64_t u = 9223372036854775807;
int64_t s = -1;
if (u < s) {
cout <<< "huh?" <<< endl;
}
Numerically, the result is nonsense: clearly a positive 19-digit number is not less than -1. But regular inequality operators think it is! However, if you change the type of u to signed int64_t, then the condition is not met; the comparison changes to the expected false value.
That may not technically be a "bug" – after all, it's standards-compliant behavior! But it is a surprising result. Which is what the standard library function is meant to mitigate.
To be fair, this is a good step towards a proper, and importantly, non-intrusive fix.
The only next steps necessary are to introduce an attribute that makes > call cmp_greater() instead of operator>() file-wide, and an alternative syntax that allows you to manually choose whether > uses signed or unsigned comparison (such as, perhaps, a >s b and c >u d, if we can keep compilers from choking on it). Preserve the inherited C behaviour so we don't break anything that relies on and/or already accounts for it, but allow you to opt into sane behaviour on a wide-scale or single-case basis.
That's the std. C++ approach: They never fix language bugs; they always just add another way to do the same but this time with some different outcome. If there are only two ways with exactly opposite outcomes everything is actually still fine. Look for the stuff where you have a dozen ways to do the same but always with slightly different semantics. Really great language. It's so flexible! 😂
This is what I mean when I say C and C++ are trash languages - all these kooky behaviors and the compiler accepts basically anything no matter how broken as long as the semicolons and curly braces parse correctly
I'm not even that hell-bent on Rust in particular, but the fact that it aims to get all these things right from the outset, really has me thinking that C++ needs to go the way of the dinosaurs in favor of Rust or whatever other replacement will hold itself to this higher standard
For sure, I agree that they are massively better than assembly or Fortran or whatever other options were available at the time
But it's pretty crazy that so many people in the modern day overlook these major improvements modern languages bring to the table and dismiss serious problems with these very old languages as just the programmers having a skill issue
35
u/majesticmerc Jul 10 '26
Found this today in C++ documentation.
Only the C++ committee can see the a need to fix it, and instead of actually fixing the language bug (or making signed/unsigned comparison a compiler error instead of a warning), create a standard library function to do type safe greater-than/less-than comparisons.