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

231–240 of 395 posts

Re: Modern C++ Won't Save Us

#231

Post by fetbaffe »

pjmlp wrote: post #225
fetbaffe wrote: post #209

Without any data to back this up, my guess is that there is no good reason to pick C++ for a new project except when the developer is already fluent in C++. Assume we have this abstract developer that has a good knowledge in programming theory but has no experience in programming languages. The developer starts a new project, but in what language? web: Don't see any reason for this. Exist lots of great alternatives.…

NVidia is designing their GPUs with C++ in mind as source language. desktop-GUI: I guess you might be joking here with Electron, I rather use my GPU for something else other than blinking cursors. Even with Cocoa, UWP and WPF, the underlying UI shaders are written in C++. Embedded: Yes, C does rule over C++, which is a reason why embedded is so open to security exploits due to wrong manipulation of string and arrays.…

desktop-GUI: I'm not a fan of Electron either, however the community seems not to be joking about picking it. It seems like most projects are going that direction. None of your arguments here are about a new projects, just about existing technologies.

Embedded: But how is that an argument for C++? I can do safe stuff in Lua without the hassle of C++ & then use C when needed.

Parallellism: Agree. Here we have a case.

Scientific: Yes, someone needs to write the underlying libraries for Python & Matlab, but if you are starting a new project, do you actually start writing a library first or do you use an existing one?

IDE tooling: Yes, good tooling can be a good argument in itself to pick a technology. With C++ maturity is as a clear advantage, however some of the languages that i listed do have quite nice tooling today, e.g. C# & TypeScript.

Re: Modern C++ Won't Save Us

#232

Post by gpvos »

geezerjay wrote: post #146
colanderman wrote: post #95

Earlier quoted context omitted.

What parts specifically? By my estimation, the only non-deprecated part of the standard library that really reeks of pre-C++11 (what I believe most consider the advent of "modern") is iostream. Most of e.g. the containers have been kept up to date with new features of the language (e.g. move semantics, constexpr). The standard library certainly is lacking things which are commonly used (say, JSON parsing or database…

> The standard library certainly is lacking things which are commonly used (say, JSON parsing or database connection), I strongly disagree. It's quite obvious that the C++ standard library does not need to add support for "common things", because they already exist as third-party modules. In fact, this obsession to add all sorts of cruft to the C++ standard is the reason we're having this discussion. If there is no w…

You're not disagreeing with colanderman:

> (and IMO the correct decision)

Re: Modern C++ Won't Save Us

#233

Post by 0815test »

blub wrote: post #167
mannykannot wrote: post #20

Earlier quoted context omitted.

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.

The questions are worth asking. But the Rust crowd is not asking questions, they're dictating solutions, or rather that one old solution of rewriting everything to Rust. Meanwhile the Firefox rewrite, the premium example of what they propose is still plodding along and Mozilla PR blogs aside, Firefox is still plugging vulnerabilities in each release and will be for the foreseeable future. Now let's look at the Swift…

> That's how one grows a language, through building successful projects, staying positive (and having an entire platform behind it). Not through doomsday scenarios and a constant barrage of criticism.

This is exactly what the Rust community is doing! RIIR is something that's only really insisted on for relatively small pieces of security-critical code. With huge codebases like Firefox the rewrite is done piecemeal, to put the rewritten code in use as quickly as possible. The "doomsday scenario" talk about memory-unsafe languages does not come from people writing Rust, it mostly comes from the security community, even at places like Microsoft - because guess what, they've literally been running around with their hair on fire for decades, and they're sick of this especially now that something like Rust is available!

Re: Modern C++ Won't Save Us

#234

Post by comex »

tpolzer wrote: post #178
dodobirdlord wrote: post #170

Earlier quoted context omitted.

> I've also written plenty of C++ code without memory bugs. The classic response to this is "That you know of." Consider that even quality-conscious projects with careful code review like Chrome have issues like this use-after-free bug from time to time. https://googleprojectzero.blogspot.com/2019/04/virtually-unl... So when people claim that they personally don't write memory bugs I tend to assume that they are mist…

Chrome is in an exceptionally hard place because of its JIT. Your language cannot tell you if it's safe for your JIT to omit a bounds check.

That post describes two vulnerabilities: one is in the JIT, but the other one is in regular old C++ code. More generally, JIT bugs are a relatively small minority of browser vulnerabilities. More often you see issues like use-after-free in C++ code that interacts with JS, such as implementations of DOM interfaces, but the issues are not directly JIT related and would be avoided in a fully memory-safe language.

Re: Modern C++ Won't Save Us

#235

Post by comex »

gmueckl wrote: post #230
adrianN wrote: post #228

Earlier quoted context omitted.

A type system changes the need for test coverage because it eliminates whole classes of bugs statically that would need an infinite amount of tests to eliminate dynamically.

That leaves an infinite amount logic bugs to be tested for. Types cannot fix interface misuse at integration and system level. So no, this does not reduce the need for testing.

Whether they reduce the need for testing overall is arguable. But what matters in this discussion is that types can guarantee memory safety, meaning that the cases that you forgot to test – and there will always be such cases, no matter how careful you are (just look at SQLite) – are less likely to be exploitable.

Re: Modern C++ Won't Save Us

#236

Post by nunjee »

ajross wrote: post #58
magila wrote: post #53

Earlier quoted context omitted.

While there are obviously still cases where C++ makes sense to use today, those case are overwhelmingly based on the age and maturity of the C++ ecosystem. Now that Rust has proven that a language can provide memory safety without compromising (much) on performance, it is clear that the scope of C++'s supremacy is in permanent decline. As Rust (or another language with similar safety/performance properties) matures a…

> In other words: C++ is the new Fortran. Which makes Rust the new... APL? I think the analogy is pretty apt as far as it goes. Fortran by the 70's was a crufty language with a bunch of legacy mistakes that remained very popular and very useful and would continue to see active use for decades to come. And everyone knew that. And everyone had their own idea about the great new language that was "clearly" going to repl…

happy workaday Rust hacker here. Coming from higher level languages, the semantics make much more sense to me, after a quite harsh learning curve and some un-learning. Non lexical lifetimes is a game changer for rust learnability I think, and I more and more fail to see usecases where I can't just use it.

Re: Modern C++ Won't Save Us

#237

Post by otikik »

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.

I am going to postulate here that a language standard which includes undefined behaviour is not really a standard.

Re: Modern C++ Won't Save Us

#238

Post by comex »

jcelerier wrote: post #191
Tracist wrote: post #116

Earlier quoted context omitted.

> 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.

> https://jaxenter.com/security-vulnerabilities-languages-1570... there's a world in terms of safety between C and C++.

The comparison in that link is pretty meaningless; it scores languages by how many vulnerabilities have been reported in code written in them, without even making an attempt to divide by the total amount of code written in them, let alone account for factors like importance/level of public attention, what role the code plays, bias in the dataset, etc.

Re: Modern C++ Won't Save Us

#239

Post by masklinn »

noselasd wrote: post #212
masklinn wrote: post #197

Earlier quoted context omitted.

> The point of those features is that you build in debug mode or with whatever your standard library's debug macro is to fuzz your code, but then don't inflict branches on every dereference for the release mode. That's completely insane. If there's always a value in your optional it has no reason to be an optional, if there may not be a value in your optional you must check for it.

Sure, but that's not the issue. You should be using a std::optional like e.g. if (my_optional) do_stuff(*my_optional); Here's one (explicit)conditional. However if the dereferencing, *my_optional, should be safe, it too would need to perform a conditional check behind the scenes. But it doesn't - as C++ places that on the programmers hand to not sacrifice speed

Hence going back to the original issue I pointed:

> C++ does not really provide the facilities necessary for convenient, memory-safe and fast APIs.

> You should be using a std::optional like e.g. […] if the dereferencing, *my_optional, should be safe

And once again a terrible API puts the onus back on the user to act like a computer.

Re: Modern C++ Won't Save Us

#240

Post by masklinn »

pjmlp wrote: post #202
masklinn wrote: post #179

Earlier quoted context omitted.

> It is true, C++ has several warts some of them caused by the copy-paste compatibility with C. I mean that's a bit of a cop-out given C++ has more non-C warts and UBs than it has C warts and UBs at this point. It's not just "copy-paste compatibility with C" which made std::unique_ptr or std::optional deref and UB.

Sure it is, because they need to be compatible with C pointer semantics. The large majority of C++ UB comes from compatibility with ISO C UB 200+ documented cases. And ISO C++ working group is trying to reduce the amount of UB in ISO C++, which is exactly the opposite of ISO C 2X ongoing proposals.

> Sure it is, because they need to be compatible with C pointer semantics.

They don't need to be compatible with unsafe / UB C pointer semantics, allowing them to both contain garbage and be deref'able were explicit decisions the C++ committees did not have to make but chose to.

Post reply on HN