Herb Sutter on increasing safety in C++

Posted Mar 13, 2024 3:49 UTC (Wed) by atai (subscriber, #10977)
In reply to: Herb Sutter on increasing safety in C++ by pctammela
Parent article: Herb Sutter on increasing safety in C++

In 2030, Rust would be an language without a coherent language design with great tooling (by the standard at that time)

Herb Sutter on increasing safety in C++

Posted Mar 13, 2024 11:53 UTC (Wed) by pctammela (guest, #126687) [Link] (20 responses)

That is a possibility not a certainty but it's fair to say there's a lot of vocal people in the Rust community that doesn't want it to become the "new C++" with better tooling

Herb Sutter on increasing safety in C++

Posted Mar 13, 2024 17:27 UTC (Wed) by atai (subscriber, #10977) [Link] (19 responses)

C++ was and is a coherent language design with great tooling compared to C, in 1987 or 1995 or 2004. You cannot deny that. History cannot be denied.

Herb Sutter on increasing safety in C++

Posted Mar 14, 2024 1:12 UTC (Thu) by pctammela (guest, #126687) [Link] (3 responses)

Backward compatible undefined behavior sure is the pinnacle of language design in the 90s /s.
The numbers speak for themselves and Rust is a capable alternative for even the hardcore cases. It's time for C/C++ to retire.

Herb Sutter on increasing safety in C++

Posted Mar 14, 2024 21:59 UTC (Thu) by pawel44 (guest, #162008) [Link]

< The numbers speak for themselves and Rust is a capable alternative for even the hardcore cases. It's time for C/C++ to retire.

Being capable doesn't mean it's a good replacement.

Herb Sutter on increasing safety in C++

Posted Mar 15, 2024 18:44 UTC (Fri) by bartoc (guest, #124262) [Link] (1 responses)

UB is a consequence of standardization.

Much of Rust's UB corresponds exactly to LLVM UB, and C++ has more UB than just that, and sometimes implementations end up providing consistent behavior for some UB without going through the standards process (just by happenstance, and vendors have incentives not to differ from other implementations for "no reason"). C makes this even more obvious.

Herb Sutter on increasing safety in C++

Posted Mar 15, 2024 23:01 UTC (Fri) by khim (subscriber, #9252) [Link]

> Much of Rust's UB corresponds exactly to LLVM UB

Not precisely. Some UBs were ingrained pretty deeply into LLVM and required patches to handle them.

One example is “forward progress” UB was ingrained into LLVM pretty deeply and it took a lot of effort to make it non-UB.

But it was critical for the ability to claim that normal, safe, Rust couldn't generate UB (at least not easy, without [ab]using soundness bugs in the compiler), so that was done.

> just by happenstance, and vendors have incentives not to differ from other implementations for "no reason"

We are way past the point where that was true. Just look on this [recent] gem. Someone have added this nice “optimization” which is pretty much [ab]uses UB to break code which it's author have always considered valid.

Is “we have saved 0.1% on some benchmark at the cost of putting few new mines on the well-trodden road” good enough justification?

> If people in the C/C++ community would have actually talked to each other then it would have been easy to change the rules (in the backward incompatible manner, mind you!) to make language safer.

But if C/C++ couldn't even accept any changed that would just make already existing code safer then what hope is there that these “security profiles” would be adopted by anyone?

Herb Sutter on increasing safety in C++

Posted Mar 14, 2024 1:27 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

Uhm... "Coherent"?

C++ has quite a schizophrenia. For example, the C++ standard relies heavily on exceptions, the STL is not feasible without them. Yet half of the current large C++ users prohibit exceptions.

Herb Sutter on increasing safety in C++

Posted Mar 14, 2024 9:40 UTC (Thu) by taladar (subscriber, #68407) [Link]

As someone who actually used C++ in 2004, no, it absolutely wasn't coherent language design back then either and it never had great tooling.

Herb Sutter on increasing safety in C++

Posted Mar 14, 2024 10:42 UTC (Thu) by tialaramex (subscriber, #21167) [Link] (12 responses)

Of those dates you gave an ISO C++ standard only exists in 2004 (it's C++ 98) so for the others what C++ is might be whatever Bjarne says it is, now, or then, or at some other time or in some other place (e.g. Bjarne has written a number of papers for ACM SIGPLAN) and it's useless to argue about it.

But for C++ 98 we can say that this isn't a coherent design. The jump out incoherence is the provision of "I/O streams" a pet project of Bjarne Stroustrup - contrasting against an admonition that overloads of the C++ operators should reflect the operator's usual meaning and not invent new meanings. Does std::cout << count << " things were counted.\n"; really reflect the usual meaning of a shift operator?

Bjarne's excuse is to declare that actually this isn't a shift operator, it's a different operator which just happens to have identical spelling and identical precedence (even though that makes no sense). The response ought to be uproarious laughter, but instead this seems to have been taken quite seriously.

But OK, maybe we'll give I/O streams a pass, what about the general operator overloading scheme. The short circuiting boolean operators && and || can be overloaded in C++. What happens to our short circuiting for this scenario? We might expect some pretty fancy footwork is needed to deliver a way to overload the operator and yet provide short circuiting behaviour - nope C++ just doesn't offer short circuiting for the overloaded operator, too bad.

You compare against C, but C doesn't have these coherency problems. So in these respects C++ is not better it's worse

Herb Sutter on increasing safety in C++

Posted Mar 14, 2024 11:42 UTC (Thu) by ianmcc (subscriber, #88379) [Link] (11 responses)

I/O Streams might have been a good idea in 1998, but I don't think it is anyone's favorite part of modern C++. It is on the way out; std::format in C++20 and std::print family in C++23 is a great replacement. Not sure about formatted input though, it would be good to get a nice replacement for operator>> too.

Overloading && and || isn't very common, the only times I can recall seeing it is in dubious attempts at a DSEL where short-circuit evaluation doesn't make sense anyway. Do you have a use case for overloaded && or || where you also want short-circuit evaluation?

Herb Sutter on increasing safety in C++

Posted Mar 14, 2024 19:59 UTC (Thu) by roc (subscriber, #30627) [Link] (10 responses)

When you deprecate fundamental parts of the standard library, like I/O and iterators, it's not really the same language anymore. Thus claims like "C++ is so widely used" and "so many people know C++" always need to be qualified with which version of C++ is used or well-known.

Herb Sutter on increasing safety in C++

Posted Mar 14, 2024 23:38 UTC (Thu) by khim (subscriber, #9252) [Link] (9 responses)

> Thus claims like "C++ is so widely used" and "so many people know C++" always need to be qualified with which version of C++ is used or well-known.

Is Rust any different? How many Rust developers don't know nuianced things like how PhantomData affect variance of arguments and, heck, how to even properly use HRBTs?

Probably as many as C++ users who have no idea what template template parameter is and whether you can pass template function via such parameter.

Both languages are way too large and complex for an average developer to know all the nuances.

Herb Sutter on increasing safety in C++

Posted Mar 15, 2024 0:21 UTC (Fri) by roc (subscriber, #30627) [Link] (2 responses)

Not knowing all the nuances is a very different issue from "we have completely changed the recommended ways to do stream I/O, iterators, and error handling".

The Rust code I wrote 8 years ago is still, as far as I know, reasonably idiomatic today. Maybe there are some uses of the try! macro that should be ?, but that's trivial.

Herb Sutter on increasing safety in C++

Posted Mar 15, 2024 10:10 UTC (Fri) by khim (subscriber, #9252) [Link] (1 responses)

> The Rust code I wrote 8 years ago is still, as far as I know, reasonably idiomatic today. Maybe there are some uses of the try! macro that should be ?, but that's trivial.

Rust still is relatively young and unfinished. For the first 13 years of it's existence C++ was relatively stable, too. Only auto_ptr was first deprecated, then removed and replaced with unique_ptr.

But eventually it was realized that you couldn't efficiently bolt-on movable types into C. You need to redesign the whole language.

Rust is repeating this same story with async. Currently async is very much a bolt-on (like rvalue references in C++), but there are discussions about how to make code async-agnostic, and so on.

I wouldn't be surprised to find out that in year 2030 it would be realized that we couldn't integrate these things into Rust and a new language is needed.

Then around year 2040 said new language would finally materialize.

Would Rust developers act like C++ users today? Only time will tell.

Herb Sutter on increasing safety in C++

Posted Mar 15, 2024 20:54 UTC (Fri) by roc (subscriber, #30627) [Link]

It's impossible to know what kind of mistakes Rust devs will make in the future. If they make dramatic changes that makes lots of existing code non-idiomatic, I hope at least they'll be honest about the retraining that will be necessary.

Herb Sutter on increasing safety in C++

Posted Mar 15, 2024 9:22 UTC (Fri) by farnz (subscriber, #17727) [Link] (5 responses)

This isn't the same as "doesn't know the nuance". This is the equivalent of Rust saying "println!, eprintln! and the Debug and Display traits have been removed. You will need to manually replace them to update your code, and there is no automatic fixer".

Herb Sutter on increasing safety in C++

Posted Mar 15, 2024 11:43 UTC (Fri) by ianmcc (subscriber, #88379) [Link] (4 responses)

IOStreams will never be removed from C++ though. I doubt it will ever get deprecated, it can just coexist.

Herb Sutter on increasing safety in C++

Posted Mar 15, 2024 12:08 UTC (Fri) by farnz (subscriber, #17727) [Link] (2 responses)

And therein lies the problem for any "safety" improvements in C++; if you merely deprecate the parts that aren't memory-safe, and allow them to coexist, people will stick with their old habits. If you remove them, then existing C++ breaks, and breaks badly, requiring people to relearn the language.

This is the challenge for any language trying to make a change that involves removing existing features that people make use of; do you remove those features and break existing users in the hope of attracting new ones, or do you leave them in place and risk people ignoring the change you want to make? Note that for memory-safety, not removing the features people use that are unsafe means that I can compile with any profile set and code that's not memory-safe will continue to compile without a diagnostic like it does today - and that's a big challenge that no language I'm aware of has an answer to (even Rust's editions don't fully answer this problem).

Herb Sutter on increasing safety in C++

Posted Mar 15, 2024 16:59 UTC (Fri) by Wol (subscriber, #4433) [Link] (1 responses)

Switching on a safety profile should also switch on a "warn on deprecated features" flag.

Pain in the arse, but for anybody who is serious enough to switch on a safety profile, they should be prepared to deal with the fallout. As I've said before, when I inherited a dodgy codebase, I just slowly ratcheted up the warning level, fixing things as they came up, until it got rid of most of the bugs without me ever actually finding half of them ... :-)

Cheers,
Wol

Herb Sutter on increasing safety in C++

Posted Mar 15, 2024 18:50 UTC (Fri) by farnz (subscriber, #17727) [Link]

But the moment you start issuing a diagnostic for C++ features that the profile bans, you've reduced the value of the profile significantly; if you were willing to rewrite the codebase to fix the issues, the cost savings of "rewrite in C++ with safety profile, use a C++ without safety profile compiler for the bits that aren't yet fixed" aren't significant compared to "rewrite in Rust, use cxx.rs to allow you to keep reusing all the C++ code that's not yet rewritten".

If the "safety profile" idea had reached usable status before Rust reached 1.0, then it would have a decent chance; but it's competing against a social reality where the people most willing to change the way they work have moved to Rust over the last 8 and a bit years, and the longer it takes to arrive, the fewer people will be left willing to learn a new language called "C++ with safety profile" but not a new language called "Rust".

Herb Sutter on increasing safety in C++

Posted Mar 15, 2024 21:07 UTC (Fri) by roc (subscriber, #30627) [Link]

This is bad in its own way. Say you've worked on a large C++ project for a long time, and it uses streams, exceptions, the STL, header files and so on. Then you get a job working on another C++ project in a similar domain to your previous project --- should be fine, because you "know C++" right? But it turns out you have to learn modules, std::format, ranges, and whatever error handling patterns they use instead of exceptions --- just to write the same kind of code you were writing before. And we're not talking about corner cases, but features you use everywhere.

Herb Sutter's plans would add safety rules to that list.

I'm not saying it's overall bad to evolve the language in this way. It's probably overall good. But when you make these changes you need to be honest and admit that to some extent, you've forked the language and developer community.