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

181–190 of 395 posts

Re: Modern C++ Won't Save Us

#181

Post by nimrody »

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

The difficulty here is combining multiple libraries each using its own abstractions.

For example, since the standard library does not have a Matrix class suitable for numerical applications (or maybe it does today...) using multiple libraries each with its own Matrix class is difficult. Multiple libraries are needed since one library may not contain all numerical algorithms one may require for a given app.

This is not a problem for Google where I assume everyone is using internally written code -- but is a problem for most of us.

Re: Modern C++ Won't Save Us

#182

Post by Vogtinator »

geofft wrote: post #62
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.

All of those problems are long-term solved by using more Rust, whereas none of C++'s problems are long-term solved by using more C++. (Personally, I don't find single-vendor or lack of standardization a problem in practice, and I've never written C++ for a platform Rust doesn't support.)

Both of them can be solved by giving it more time, but C++ is currently way ahead.

Re: Modern C++ Won't Save Us

#183

Post by netheril96 »

petters wrote: post #145
blt wrote: post #127

Earlier quoted context omitted.

How is the prng over engineered? I agree its a little clunky for casual use but it makes all the right decisions, imo, for serious use of prngs (e.g. reproducible experiments for Monte Carlo methods in simulation and statistics)

Initializing the mersenne twister is really hard: https://github.com/PetterS/monolith/blob/master/minimum/core... Edit: There are two links in the code with more info.

Most other random libraries, in whatever languages, do not even offer the option of this "right" version of initialization. They all just seed with a 32-bit integer. If you are content with those libraries, you should be content with a simple `std::mt19937{std::random_device{}()}`.

Re: Modern C++ Won't Save Us

#184

Post by nimrody »

dpc_pw wrote: post #120
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.

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

Sometimes different vendors provide some benefits. For example Intel's C++ compiler produces (or used to produce?) much more efficient numerical code than either gcc or clang.

So for numerical applications C++ may make more sense than Rust. Rust does have the advantage of being based on an LLVM backend. So perhaps different vendors can compete by writing more efficient backends that are applicable to both C++ and Rust (but you probably lose some information when skipping the compiler front end)

Re: Modern C++ Won't Save Us

#185

Post by gmueckl »

dodobirdlord wrote: post #170
paulmooreparks wrote: post #134

Earlier quoted context omitted.

Why is it difficult to believe? I've also written plenty of C++ code without memory bugs. It's not that hard if you play by a few simple rules.

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

Re: Modern C++ Won't Save Us

#186

Post by jcelerier »

masklinn wrote: post #159
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…

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

Re: Modern C++ Won't Save Us

#187

Post by Y_Y »

rootlocus wrote: post #163
ncmncm wrote: post #125

Earlier quoted context omitted.

The whole point of C++ is that it enables writing more powerful libraries, capturing semantics in libraries that can then just be used. C++ is still quite a lot more powerful for this purpose than Rust. Rust will get better at it, over time, but it has a long way to go and C++ is not siiting still. Rust is still a niche language, and if its rates of adoption and improvement do not keep up, it will remain a niche lang…

Is this the "no serious programmer" fallacy?

No true hn commenter would make such a mistake.

Re: Modern C++ Won't Save Us

#188

Post by jcelerier »

nimrody wrote: post #181
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).

The difficulty here is combining multiple libraries each using its own abstractions. For example, since the standard library does not have a Matrix class suitable for numerical applications (or maybe it does today...) using multiple libraries each with its own Matrix class is difficult. Multiple libraries are needed since one library may not contain all numerical algorithms one may require for a given app. This is no…

> For example, since the standard library does not have a Matrix class suitable for numerical applications (or maybe it does today...) using multiple libraries each with its own Matrix class is difficult.

well, Python comes with a builtin "matrix-like" array type and yet it's not the one which is the most used in scientific computation.

Re: Modern C++ Won't Save Us

#189

Post by jcelerier »

geezerjay wrote: post #153
hak8or wrote: post #91

Earlier quoted context omitted.

Can you or others post such alternative standard libraries? The only ones that come to mind are boost (which is a nightmarefor compile times and I feel is a mishmash of old and new) and googles absiel which I haven't actually tried enough to make an opinion about.

> Can you or others post such alternative standard libraries? POCO comes to mind. https://pocoproject.org/

Also Qt is basically a Java-like library, with bulit-in stuff for networking, GUI, XML, JSON, WebSockets, multimedia, etc.

Or you have some "domain-specific" libraries like OpenFrameworks which is very nice if you are making visual art since it comes with a lot of very simple primitives to draw shapes, etc.

Re: Modern C++ Won't Save Us

#190

Post by systemBuilder »

Many of the problems he talks about come from the lunacy of the C++ compiler making all sorts of temporaries and calling hidden type conversion functions, making all sorts of assumptions that it should never ever ever make without being told by the programmer. That is why C will always be a better language than c++ on a fundamental level. In this area stroustrup took C in a bad direction.
Post reply on HN