Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Modern C++ Won't Save Us

alexgaynor.net

Post reply on HN
Print view View original

111–120 of 395 posts

Re: Modern C++ Won't Save Us

#111

Post by safercplusplus »

jasonhansel wrote: post #36

Can someone at least make a linter that ensures you only use a "safe" subset of C++?

Others disagree, but I suggest that someone could make such a linter. As others point out, the Core Guidelines "lifetime profile checker"[1] is designed to be an advanced static analyzer that restricts how many C++ elements can be used. It's not finished yet, and the current version is not designed to achieve complete memory safety (and doesn't address data race safety). Whether or not subsequent versions could match the full safety enforcement of Rust's compiler seems to be a matter of some debate.

But there is an alternative/complementary approach, which is to simply avoid potentially unsafe C++ elements, like pointers/references, arrays, std::string_views, std::threads, etc., substituting them with safe, largely compatible replacements[2]. This approach has the benefit that an associated safety-enforcing "linter" would not impose the same kinds of "severe" usage restrictions that the lifetime profile checker (or, say, the Rust compiler) does.

[1] https://devblogs.microsoft.com/cppblog/lifetime-profile-upda...

[2] https://github.com/duneroadrunner/SaferCPlusPlus

edit: grammar

Re: Modern C++ Won't Save Us

#112

Post by throwupaway123 »

sayusasugi wrote: post #99

Any HN post mentioning C++ will inevitably be invaded by the Rust Evangelism Strikeforce.

The Rust Evangelism Strikeforce only exists in completely inane comments like yours, maybe instead of posting memes you comment on the actual content of the article not the headline?

Re: Modern C++ Won't Save Us

#113

Post by Gibbon1 »

tatersolid wrote: post #41
namirez wrote: post #7

This has been discussed extensively in the C++ community. I think if you need a very safe code, you shouldn't use the string_view or span without thinking about the potential consequences. These are added to the language to prevent memory allocation and data copy for performance critical software. Herb Sutter has concrete proposals to address this issue and Clang already supports them: https://www.infoworld.com/artic…

> think if you need a very safe code, you shouldn't use the string_view or span without thinking about the potential consequences. That’s the whole point: your caveat shows that’s it’s C/C++ which are unsafe in their very nature and therefore should not be used in code exposed to potentially malicious (e.g. user or network) input. Which is just about everything useful. HPC are generally closed systems and have differ…

> needs to run (not walk) away from C/C++ for the majority of use cases.

I think we need to stop talking about C/C++ as if they are particularly related. My opinion about performance and C is I'll happily give up some of that for better security.

Re: Modern C++ Won't Save Us

#114

Post by ncmncm »

tatersolid wrote: post #41
namirez wrote: post #7

This has been discussed extensively in the C++ community. I think if you need a very safe code, you shouldn't use the string_view or span without thinking about the potential consequences. These are added to the language to prevent memory allocation and data copy for performance critical software. Herb Sutter has concrete proposals to address this issue and Clang already supports them: https://www.infoworld.com/artic…

> think if you need a very safe code, you shouldn't use the string_view or span without thinking about the potential consequences. That’s the whole point: your caveat shows that’s it’s C/C++ which are unsafe in their very nature and therefore should not be used in code exposed to potentially malicious (e.g. user or network) input. Which is just about everything useful. HPC are generally closed systems and have differ…

There is no such language as C/C++. There is C, which cannot be written safely, and there is C++, which can be, and quite often is.

It has been many years since I shipped a memory bug in C++. It is just not a real worry for me. I am constantly dealing with design, specification, and logic flaws, which affect Rust equally, or moreso.

I am aware that there are plenty of other programmers out there, writing bad code in what they would call C++. I would like them to write good code. If it takes Rust to make them write good code, so be it. But if they began writing decent C++ code, that is just as good.

The threshold is not zero memory errors. The threshold is many fewer memory errors than logic or design errors. The more attention your language steals from logic and design, the more of those errors you will have. Such errors have equally dire consequences as memory errors, and are overwhelmingly more common in competent programmers' code, in C++ and in Rust.

C++ is (still) quite a substantially more expressive language than Rust, which is to say it can capture a lot more semantics in a library. Every time I use a powerful, well-tested library instead of coding logic by hand because it can't be captured in a library, that is another place errors have no opportunity to creep in.

So it's great that Rust makes some errors harder to make, but that is no grounds for acting holier-than-thou. Rust programmers have simply chosen to have many more of the other kinds of errors, instead.

Every programmer who switches from C to Rust makes a better world; likewise Java to Rust, or C# to Rust, or Go to Rust. Or, any of those to C++.

Switching from C++ to Rust, or Rust to C++, is of overwhelmingly less consequence, but the balance is still in C++'s favor because C++ still supports more powerful libraries.

You might disagree, but it is far from obvious that you are correct.

Re: Modern C++ Won't Save Us

#115

Post by kccqzy »

nitwit005 wrote: post #107

The string_view issue has popped up even in relatively safe languages. Java's String class used to do something similar, where substring returned a String that referenced the original String object's internal array to avoid a copy. They gave up on it because too many people accidentally held a references to large strings and leaked memory that way.

As far as I know, this is rather popular. Haskell's ByteString and Text still types do the same. So does Rust, where most of the time you are very consciously borrowing the original string instead of making copies.

Re: Modern C++ Won't Save Us

#116

Post by Tracist »

ncmncm wrote: post #114
tatersolid wrote: post #41

Earlier quoted context omitted.

> think if you need a very safe code, you shouldn't use the string_view or span without thinking about the potential consequences. That’s the whole point: your caveat shows that’s it’s C/C++ which are unsafe in their very nature and therefore should not be used in code exposed to potentially malicious (e.g. user or network) input. Which is just about everything useful. HPC are generally closed systems and have differ…

There is no such language as C/C++. There is C, which cannot be written safely, and there is C++, which can be, and quite often is. It has been many years since I shipped a memory bug in C++. It is just not a real worry for me. I am constantly dealing with design, specification, and logic flaws, which affect Rust equally, or moreso. I am aware that there are plenty of other programmers out there, writing bad code in…

> It has been many years since I shipped a memory bug in C++. It is just not a real worry for me.

The whole comment sounds so much like well written satire, but I think he's being serious.

Re: Modern C++ Won't Save Us

#117

Post by ncmncm »

_bxg1 wrote: post #75
jclay wrote: post #14

I really don't get all the hate that C++ gets. The suggested alternatives in the article are Rust and Swift. What if you need to develop a cross platform GUI, that has a backend running a CUDA or OpenCL algorithm? For the former, you can use Qt, which isn't without it's warts, but is pretty tried and true in my experience (see KDE, VTK, etc). For the latter, you'll end up writing your CUDA code in C++ anyways. I gues…

But most of the things you just listed are just aspects of the existing ecosystem (libraries, tooling, etc.). There's no doubt C++ has an incredibly large ecosystem and will therefore be around for quite a while to come, but that doesn't make it a good language , it just makes it one that happens to have been very popular for a very long time. Our industry is one that values progress over tradition in the long run. I…

That doesn't make C++ a good language. It just is one.

Rust is also a good language. Trash-talking C++ does no one any good.

Overwhelmingly, the substantial gains to be made are moving people off of C. Every other possible benefit is a rounding error. It is still much easier to get people to C++. Once dislodged, they might continue on to Rust, or br seduced by C++'s greater expressive power and more powerful libraries. Either way the world will be better.

C++ today seems weighed down by legacy cruft, compared to Rust, but Rust is rapidly accumulating its own legacy cruft. By the time it is mature it will have easily as much of its own.

Re: Modern C++ Won't Save Us

#118

Post by mempko »

nradov wrote: post #108
fooker wrote: post #103

Earlier quoted context omitted.

I don't see the problem. You are free to use such a modern library (Google does, it's called absl). The good thing here is that the standard library doesn't require 'magic' to be implemented (unlike Swift where the standard library relies on hidden language hacks).

Sure it's possible to use a non-standard "standard library". But at that point you're already halfway to using a different language so why not consider switching from C++ to D / Rust / Go?

C++ is designed for people to make nice libraries. Unlike other languages there is nothing special about the standard library (no magic language hacks). All libraries are first class citizens by design.

Re: Modern C++ Won't Save Us

#119

Post by [deleted] »

mjevans wrote: post #100
School-Cotton wrote: post #85

Earlier quoted context omitted.

The problem, as far as I understand it (though I’m a layman), is that by the time the dead code optimization pass runs, the code has been transformed so much that there’s no obvious way for the compiler to tell the difference between “obvious programmer-intended null check that we shouldn’t optimize out” and “spurious dead code introduced by macro expansion” or (in C++) “by template instantiation”.

Couldn't user defined branches be tagged by such a compiler and if a tagged branch is eliminated the error generated with a reference to the tagged line in question?

[deleted]

Re: Modern C++ Won't Save Us

#120

Post by dpc_pw »

the_trapper wrote: post #16
wwright wrote: post #13

Earlier quoted context omitted.

The thing is, Rust has tools that are easier to use _and_ have great performance _and_ prevent security and stability mistakes.

However Rust is single vendor and single implementation, has a much smaller community and ecosystem than C++, is not standardized, and does not support all of the platforms and use cases that C++ does.

Except for stuff like "trusting trust", I find no need for "multiple vendors of Rust toolchains". It only comes handy when the language itself is not truly open source, and is in itself a form of a product.

Building on that " is not standardized," is not a problem, because one Open Source implementation is de facto the standard. Which I find much better than forever fixing your code, working around incompatibilities, bugs, etc. in compilers from different versions.

Which leaves "does not support all of the platforms and use cases that C++ does" which is indeed true.

Post reply on HN