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

191–200 of 395 posts

Re: Modern C++ Won't Save Us

#191

Post by jcelerier »

Tracist wrote: post #116
ncmncm wrote: post #114

Earlier quoted context omitted.

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.

> https://jaxenter.com/security-vulnerabilities-languages-1570...

there's a world in terms of safety between C and C++.

Re: Modern C++ Won't Save Us

#192

Post by barrkel »

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…

Standard libraries shouldn't include "leaf" modules, but probably should include interface / adapter modules. So no to JSON, but maybe yes to a serde interface. No to a database driver, but maybe yes to an interface like JDBC.

Without common interfaces, flexibility in implementation is much more expensive, and innovation suffers too, as new things are harder to get off the ground without existing code that they can cheaply plug into.

Re: Modern C++ Won't Save Us

#193

Post by rimliu »

fooker wrote: post #103
jandrewrogers wrote: post #71

A significant issue I have with C++ is that even if your code base is pure C++17, the standard library is a Frankenstein's monster of legacy and modern C++ mixed together that required many compromises to be made. A standard library that usefully showed off the full capabilities of C++17 in a clean way would have to jettison a fair amount of backward compatibility in modern C++ environments. I've noticed that more an…

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

What are those "hidden language hacks" in Swift?

Re: Modern C++ Won't Save Us

#194

Post by hu3 »

clouddrover wrote: post #19
jmole wrote: post #15

Question - How does one write microcontroller code (or other memory-mapped I/O code) using a memory-safe language?

Like this: https://rust-embedded.github.io/book/

That's not memory safe as the book itself states:

> Now, the volatile accesses are performed automatically through the read and write methods. It's still unsafe to perform writes, but to be fair, hardware is a bunch of mutable state and there's no way for the compiler to know whether these writes are actually safe, so this is a good default position.

https://github.com/rust-embedded/book/blob/9c05a419fc2ad231c...

Re: Modern C++ Won't Save Us

#195

Post by Someone »

Razengan wrote: post #157
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).

What are the hidden language hacks in Swift?

I wouldn’t call them hacks, but there are things in the runtime that you can’t implement yourself in Swift. Examples (corrections welcome):

- you can’t allocate memory and then turn it into an Swift object.

- you can’t write Decodable in pure Swift (reflection isn’t powerful enough to do “set the field named “foo” in this structure to “bar”)

- reference counts are hidden from Swift code (yes, there’s swift_retainCount to read them, but that’s documented as returning a random number (https://github.com/apple/swift/blob/master/docs/Runtime.md) because it should not be used). So, if the compiler emits more reference count logic than needed in the data structure that your library uses, there’s no way to improve on it.

Re: Modern C++ Won't Save Us

#196

Post by esrauch »

gmueckl wrote: post #185
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…

That is why use tools like valgrind to verify that you got it right.

When I worked on a mobile C++ project at Google, we went exceptionally out of our way to avoid memory issues.

We ran under valgrind and multiple sanitizers (and continuously ran those with high coverage unit and integration tests). We ran fuzzers. We had strictly enforced style guides.

We still shipped multiple use after frees and ub-tripping behavior. I also saw multiple issues in other major libraries that we were building from source so it can't be pointed at as just incompetency on my team.

Basically, it might be possible but I think it's exceptionally more difficult to write memory safe C++ than this thread is making it sound.

Re: Modern C++ Won't Save Us

#197

Post by masklinn »

jcelerier wrote: post #186
masklinn wrote: post #159

Earlier quoted context omitted.

> A significant issue I have with C++ is that even if your code base is pure C++17, the standard library is a Frankenstein's monster of legacy and modern C++ mixed together that required many compromises to be made. A standard library that usefully showed off the full capabilities of C++17 in a clean way would have to jettison a fair amount of backward compatibility in modern C++ environments. Not to mention C++ does…

> (namely that you can just deref' an std::optional and it's UB if the optional is empty). if that was not the case, `optional` would get exactly zero usage. 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.

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

Re: Modern C++ Won't Save Us

#198

Post by systemBuilder »

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

In the article the compiler noticed that because of the loop iterator reading the array a[i+1] ... under the assumption the program never indexed beyond the end of the array ... The compiler assumed the loop variable was always less than the limit and therefore changed the loop into an infinite loop. This is the insanity of some of the newer compilers which assume your program never performs an undefined behavior. They compile your mildly buggy slightly undefined code into shit*.

Re: Modern C++ Won't Save Us

#199

Post by adrianN »

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…

I believe that C++ needs a fat standard library because using third party libraries is a bit cumbersome in C++. Alternatively there could be a blessed build system that makes third party library integration as easy as Cargo or Go Modules.
Post reply on HN