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

41–50 of 395 posts

Re: Modern C++ Won't Save Us

#41

Post by tatersolid »

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 different threats, but the industry just needs to run (not walk) away from C/C++ for the majority of use cases.

Re: Modern C++ Won't Save Us

#42

Post by 0815test »

jasonhansel wrote: post #36

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

The answer is essentially no, at least if you're seeking substantial levels of assurance or safety. Even the C++ Core Guidelines effort, https://github.com/isocpp/CppCoreGuidelines which is the closest thing to what you describe and is driven by influential members of the ISO C++ community including B. Stroustrup, does not claim that they'll be able to make C++ memory safe.

Re: Modern C++ Won't Save Us

#43

Post by steveklabnik »

jasonhansel wrote: post #36

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

The Core Guidelines are an attempt at this, but it’s not fully safe. Safer, which matters! But not safe.

There isn’t really any useful safe subset of C++. If there were, Rust may never have been created in the first place.

Re: Modern C++ Won't Save Us

#44

Post by kevin_thibedeau »

raphlinus wrote: post #10

From the article: > Dereferencing a nullptr gives a segfault (which is not a security issue, except in older kernels). I know a lot of people make that assumption, and compilers used to work that way pretty reliably, but I'm pretty confident it's not true. With undefined behavior, anything is possible.

Definitely not true. Consider an IoT device without an MMU.

Re: Modern C++ Won't Save Us

#45

Post by bobajeff »

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…

>Not that it won't happen for Rust, but C++ also has tooling suited for enterprise use that are largely unmatched in other languages

Hopefully that stuff will be helped with things like Language Server Protocol and Debug Adapter Protocol.

Re: Modern C++ Won't Save Us

#46

Post by the_trapper »

wwright wrote: post #23
the_trapper wrote: post #16

Earlier quoted context omitted.

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.

That’s very true. But all of those communities, ecosystems, standards, and use cases have an extreme learning curve and a very deep problem with security. :-)

Rust's learning curve isn't exactly a shallow one either.

For the record I think Rust has a lot going for it, but it is not the C++ killer that many are touting it to be.

Re: Modern C++ Won't Save Us

#47

Post by Rexxar »

mannykannot wrote: post #20
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…

I do not think it helps to think in emotional terms such as 'hate'. There is nothing wrong with discussing potential problems, and the current utility of the language should not stop us asking whether we could do better in future. FWIW, I use C++, not Rust or Swift, and I have a fair amount of knowledge and experience vested in it, but I think these questions are worth asking.

> I do not think it helps to think in emotional terms such as 'hate'

I think 'hate' really represent the mind of some people (even if they are a minority) but even if we ignore this extreme, the level of irrationality in technical discussions is generally quite high. You need to have rational people to have a rational discussion. The sad reality is that a lot of technical discussions are only superficially rational and are often a political play to assert superiority on other people (it's true for languages, frameworks, code editors, methodologies, etc ... ).

Re: Modern C++ Won't Save Us

#48

Post by 932 »

sanderjd wrote: post #27
932 wrote: post #21

Earlier quoted context omitted.

Yeah, agreed. The points in the article are valid , but quirks you learn and get past the first time. I still shoot myself in the foot sometimes even though I don't have a single bare new/malloc without a shared/unique ptr! But that's C++ for you. But, C/C++ is the best option for us for high-performance network processing. We're dabbling with Rust for small applications where we would use Python previously and it's…

> but there's no way we could use Rust for the core application yet I'd love to hear more information on this! In my mental model, you could just use Go to replace your Python utilities, but Rust might be workable for your core (or at least its designers would like it to be and would like to know why it isn't).

We are Rust noobs :-). The Python utilities are random tools and daemons, so it's been a nice experience getting my feet wet in a completely different paradigm with rustc.

So the biggest challenge with moving to another language is reproducing the same low latency and high performance we've carefully designed in C++ to a Rust analogue... which given we haven't really used Rust enough yet to have a total sense of this, is hard.

In the long future, I can see Rust working in gradual stages -- but of course focusing on biz objectives is better first when we know how to write high perf C++, hence spending time to play with Rust on side tooling or other smaller projects.

From what little Rust I've written so far I really do like it, so hoping that I can incorporate it more

Re: Modern C++ Won't Save Us

#49

Post by zaphar »

sbov wrote: post #8
781 wrote: post #3

There was an article recently about a behavior which in a recent version of C++ was made from defined behavior into undefined behavior, because making it undefined allowed for better compiler optimizations. I always thought that undefined behaviors were historical accidents. But apparently sometime people just say "hey, lets add a few more undefined behaviors" This is the insanity of C++

This sounds wrong. You're probably thinking of undefined behavior that happened to behave the same across all available C++ compilers, so people began to rely on it. But since it was technically undefined behavior, optimizers were free to take advantage of it, and when they started to it smashed any code that relied on that undefined behavior behaving in a consistent way.

While technically correct, (which is the best kind of correct), the sad reality is that de-facto standards matter. Languages that understand this tend to be safer than languages that do not.

Re: Modern C++ Won't Save Us

#50

Post by swiftcoder »

the_trapper wrote: post #46
wwright wrote: post #23

Earlier quoted context omitted.

That’s very true. But all of those communities, ecosystems, standards, and use cases have an extreme learning curve and a very deep problem with security. :-)

Rust's learning curve isn't exactly a shallow one either. For the record I think Rust has a lot going for it, but it is not the C++ killer that many are touting it to be.

It's a bona fide C++ killer for applications that are both security and performance critical. It's already gaining traction for those applications even within relatively conservative engineering organisations.

That said, there are many performance-critical applications who are not security-critical, and in those I'd expect C/C++ to persist pretty much indefinitely. And many security-critical applications which are not performance-critical, and can perfectly well be served by garbage collected languages like Java/C#/Go.

Post reply on HN