Modern C++ Won't Save Us • Hacker News Board

Re: Modern C++ Won't Save Us

#141

Post by m_mueller » Tue, Apr 23, 2019, 5:21 AM UTC

alfalfasprout wrote: post #135

tatersolid wrote: post #41

Earlier quoted context omitted.

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

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

You mention control software as an example. What makes C++ better there? My guess is compiler options for more hardware targets, but is it something else also? Is it really C++ and not C that is most prevalent on embedded systems?

Re: Modern C++ Won't Save Us

#142

Post by ncmncm » Tue, Apr 23, 2019, 5:22 AM UTC

steveklabnik wrote: post #43

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.

This is not, in fact, the case. Back when Rust was begun, it had some merit, but C++ is a rapidly moving target.

C++ still does not have an absolutely safe subset, but it has a safe-enough subset, and plenty of other merits that will ensure its continued competitiveness.

Rust will continue improving, too, and someday may be as expressive as C++ is today, or perhaps even as expressive as C++ is then. That will be a good day, although by then some other language will be on the rise, its users hoping to displace C++ and, given enough luck and hard work, Rust.

V could be interesting.

Re: Modern C++ Won't Save Us

#143

Post by near » Tue, Apr 23, 2019, 5:24 AM UTC

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…

Because C++ is my primary language, and I always work on my codebases alone, I dropped the standard library and implemented my own replacement. It's not at all practical for most I'm sure, but it allows me to evolve the library with new revisions of the C++ standard without being absolutely fixed on backward compatibility.

One of the things I did for safety is that all access methods of all of my containers will bounds check and throw on null pointer dereferences ... in debug and stable mode. And all of that will be turned off in the optimized release mode, for applications where performance is absolutely critical. The consistency is very important.

Whenever I get a crash in a release mode, I can rebuild in debug mode and quickly find the issue. And for code that must be secure, I leave it in stable mode and pay the small performance penalty.

Re: Modern C++ Won't Save Us

#144

Post by m_mueller » Tue, Apr 23, 2019, 5:26 AM UTC

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

Use cases and compiler options go hand in hand. Every implementation is a trade-off and different fields demand different trade-offs.

Re: Modern C++ Won't Save Us

#145

Post by petters » Tue, Apr 23, 2019, 5:27 AM UTC

blt wrote: post #127

millstone wrote: post #98

Earlier quoted context omitted.

I agree with this and would take it a step further, and say that recent changes to the STL are the worst parts of modern C++. For example std::regex supports 6 distinct syntaxes, the PRNG stuff is massively over-engineered, the "extensions for parallelism" add complexity without giving enough knobs for any real perf improvement. Meanwhile there's gaping holes like UTF-8 support. It's a sad state.

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.

Re: Modern C++ Won't Save Us

#146

Post by geezerjay » Tue, Apr 23, 2019, 5:28 AM UTC

colanderman wrote: post #95

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…

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 widely adopted JSON or DB library for C++ then who in their right mind would believe it would be a good idea to force one into the standard?

And don't get me started on the sheer lunacy of the proposal to add a GUI library. Talk about a brain-dead idea.

People working on other programming language stacks already learned this lesson a lot of time ago. There's the core language and there's the never-ending pile of third-party modules. Some are well-made and well thought-out, others aren't. That doesn't matter, because these can be replaced whenever anyone feels like it. This is not the case if a poorly thought-out component is added to an ISO standard.

Re: Modern C++ Won't Save Us

#147

Post by [deleted] » Tue, Apr 23, 2019, 5:30 AM UTC

alfalfasprout wrote: post #135

tatersolid wrote: post #41

Earlier quoted context omitted.

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

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

[deleted]

Re: Modern C++ Won't Save Us

#148

Post by fulafel » Tue, Apr 23, 2019, 5:32 AM UTC

alfalfasprout wrote: post #135

tatersolid wrote: post #41

Earlier quoted context omitted.

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

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

Re: Modern C++ Won't Save Us

#149

Post by fsloth » Tue, Apr 23, 2019, 5:33 AM UTC

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…

So the language is evolving, it is used by projects that are old and still in good enough shape so one can adapt their concepts to some new things, and as a sugar on top, it does not break bakcwards compatibility.

As such it just sounds like a mature technology which a huge adopted base and is still holding traction. Generally maturity, traction and adaptability can be considered indicators of health and not malady.

Beauty is overstated. Engineering can be art but it doesn't have to be.

Jokes aside, I use C++ daily and see it as Warty McWartface and could spend a long time ruminating about it's faults. But adapting old stuff to new boundaries is always going to be messy. Generally rewriting history creates more problems than solves them.

Re: Modern C++ Won't Save Us

#150

Post by geezerjay » Tue, Apr 23, 2019, 5:36 AM UTC

nradov wrote: post #108

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

Sure it's possible to use a non-standard "standard library". But at that point you're already halfway to using a different language so why not consider switching from C++ to D / Rust / Go?

> But at that point you're already halfway to using a different language

This statement makes no sense at all. Using a third-party library that's not specified by the same ISO standard that specifies the core languagr does not create "a different language".

It just means you're actually using the programming language to do stuff.

This isn't the case even if someone uses a toolkit that relies on preprocessor tricks to give the illusion of extending the core language, such as Qt.