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

241–250 of 395 posts

Re: Modern C++ Won't Save Us

#241

Post by comex »

fulafel wrote: post #148
alfalfasprout wrote: post #135

Earlier quoted context omitted.

"which is just about everything useful". This statement is wildly without merit. Sure, for the typical user facing application HN readers talk about then C++ can certainly contain vulnerabilities that are worrisome. Many performance critical applications can tolerate vulnerabilities in favor of latency. It seems to me that the world of realtime systems including avionics, autonomous control software, trading, machine…

> The extreme low level control that C++ offers and powerful metaprogramming allows for performance that even Rust cannot hope to rival. Rust has vastly better metaprogramming, and as much low level control, no? And many low-level things are well-defined in Rust, and undefined behaviour or implementation-defined in C++.

Depends. Some metaprogramming features in C++ are currently ahead of Rust (values as generic parameters, generic associated types, constexpr, etc.), but Rust is ahead in other areas (procedural macros) and is working on parity in the other cases I mentioned. Meanwhile, Rust has none of C++'s legacy cruft, and its typed, trait-based generics are arguably a better foundation for metaprogramming than C++'s "dynamically typed at compile time" template system.

Re: Modern C++ Won't Save Us

#242

Post by 0815test »

pjmlp wrote: post #169
insulanian wrote: post #152

Earlier quoted context omitted.

And rightly so! What's wrong with spreading awareness about safer alternative? If that wasn't the case in the past, we'd still be programming in Cobol and Fortran.

On the contrary, we had plenty of safer alternatives for systems programming, derived from Algol and PL/I. Then came an OS, with a symbolic price instead of the typical market prices of competing OSes, alongside source code tapes, and a systems programming language that was the "JavaScript" of system languages.

The biggest factor was that the OS was written to run on minicomputers as opposed to big iron, and was written in a portable language. Thus it could seamlessly jump over to micros (as soon as these became powerful enough, of course), and even later on to embedded and "wearable" compute. You just can't do that unless you're writing in a highly flexible and highly portable language - more like the FORTRAN of systems languages than anything like JavaScript!

Re: Modern C++ Won't Save Us

#243

Post by masklinn »

likpok wrote: post #55
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.

Does rust have a structure to handle something like a stringview?

That's one of the language's primitives: https://doc.rust-lang.org/std/primitive.str.html

Re: Modern C++ Won't Save Us

#244

Post by gmueckl »

comex wrote: post #235
gmueckl wrote: post #230

Earlier quoted context omitted.

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.

Types can only provide limited memory safety. There is a real need to deal with data structures that are so dynamic as to be essentially untyped. Granted, this usually happens in driver code for particularly interesting hardware, but it happens. Also, I have not yet seen a type system that is both memory safe and does not prohibit certain optimizations.

Re: Modern C++ Won't Save Us

#245

Post by pjmlp »

fetbaffe wrote: post #231
pjmlp wrote: post #225

Earlier quoted context omitted.

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

desktop-GUI: What community? Web devs trying to write desktop apps?

Embedded: Try to write a safe string and vector with bounds checking, or IO port access in C like in C++ type system allows for. Lua is nice for hobby, not production class hardware deployments.

Scientific: Depends, many libraries are yet to be written.

IDE tooling: Typescript and C# audience isn't the same as those using raw C++.

Re: Modern C++ Won't Save Us

#246

Post by pjmlp »

masklinn wrote: post #240
pjmlp wrote: post #202

Earlier quoted context omitted.

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.

Some people prefer a Python 2/3 community schism, others prefer that tools actually get adopted in spite of a few transition flaws.

Re: Modern C++ Won't Save Us

#247

Post by pjmlp »

0815test wrote: post #242
pjmlp wrote: post #169

Earlier quoted context omitted.

On the contrary, we had plenty of safer alternatives for systems programming, derived from Algol and PL/I. Then came an OS, with a symbolic price instead of the typical market prices of competing OSes, alongside source code tapes, and a systems programming language that was the "JavaScript" of system languages.

The biggest factor was that the OS was written to run on minicomputers as opposed to big iron, and was written in a portable language. Thus it could seamlessly jump over to micros (as soon as these became powerful enough, of course), and even later on to embedded and "wearable" compute. You just can't do that unless you're writing in a highly flexible and highly portable language - more like the FORTRAN of systems la…

Ironically, systems written in hardware 10 years older than PDP-11, thus with less resources, were written in safer system languages, go figure.

Re: Modern C++ Won't Save Us

#248

Post by simias »

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

This is solved in Rust by letting you test and unwrap at the same time:

    if let Some(obj) = my_optional {
        do_stuff(obj);
    }
>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

So basically that turns C++ optional types into fancy linter hints which won't actually improve the safety of the code much.

I understand C++'s philosophy of "you pay for what you use" but that's ridiculous, if you use an optional type it means that you expect that type to be nullable. Having to pay for a check is "paying for what you use". If you don't like it then don't make the object nullable in the first place and save yourself the test. That's just optimizing the wrong part of the problem.

Re: Modern C++ Won't Save Us

#249

Post by simias »

foobar_ wrote: post #140

Can virtualisation solve this ? Is it possible to have a virtualised environment like Qubes but for programs ?

Virtualization can help reduce the harm caused by a misbehaving program but it won't magically make the program behave correctly.

Having a program cause a memory violation and be killed by the OS is the best possible outcome in this case, it stops the program from doing any damage and you get a clear symptom of the problem for debugging.

It's when the issue is not that obvious that you're in real trouble because it may start behaving erratically, corrupt data and be exploited by malicious actors to get access to resources that shouldn't be exposed.

Re: Modern C++ Won't Save Us

#250

Post by masklinn »

simias wrote: post #248
noselasd wrote: post #212

Earlier quoted context omitted.

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

This is solved in Rust by letting you test and unwrap at the same time: if let Some(obj) = my_optional { do_stuff(obj); } >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 So basically that turns C++ optional types into fancy linter hints which won't actually…

> So basically that turns C++ optional types into fancy linter hints which won't actually improve the safety of the code much.

C++'s optionals are less "safer pointers" and more "stack-allocated pointers" (nor to be confused with pointers to stack allocations).

Post reply on HN