Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

21st Century C++

cacm.acm.org

Post reply on HN
Print view View original

211–220 of 281 posts

Re: 21st Century C++

#211

Post by ivan_gammel »

simoncion wrote: post #207
ivan_gammel wrote: post #180

Earlier quoted context omitted.

That was probably 1.4.2_15, because 1.4.15 did not exist. What you describe wasn’t a Java source or binary compatibility problem, it was a shipping problem and it did exist in C++ world too (and still exists - sharing runtime dependencies is hard). I remember those days too. Java 5 was released 20 years ago, so you describe some really ancient stuff. Today we don’t have those limits on HDD space and can simply ship a…

While "Well, just bundle in a copy of the whole-ass JRE" makes packaging Java software easier, it's still true that Java's backwards-compatibility is often really bad. > ...sharing runtime dependencies [in C or C++] is hard... Is it? The "foo.so foo.1.so foo.1.2.3.so" mechanism works really well, for libraries whose devs that are capable of failing to ship backwards-incompatible changes in patch versions, and ABI-bre…

> Java's backwards-compatibility is often really bad.

“Often” is a huge exaggeration. I always hear about it, but never encountered it myself in 25 years of commercial Java development. It almost feels like some people are doing weird stuff and then blame the technology.

> Is it? The "foo.so foo.1.so foo.1.2.3.so"

Is it “sharing” or having every version of runtime used by at least one app?

Re: 21st Century C++

#212

Post by boris »

> [M]any developers use C++ as if it was still the previous millennium. [...] C++ now offers modules that deliver proper modularity.

C++ may offer modules (in fact, it's been offering them since 2020), however, when it comes to their implementation in mainstream C++ compilers, only now things are becoming sort of usable with modules still being a challenge in more complex projects due to compiler bugs in the corner cases.

I think we need to be honest and upfront about this. I've talked to quite a few people who have tried to use modules but were unpleasantly surprised by how rough the experience was.

Re: 21st Century C++

#213

Post by TinkersW »

boris wrote: post #212

> [M]any developers use C++ as if it was still the previous millennium. [...] C++ now offers modules that deliver proper modularity. C++ may offer modules (in fact, it's been offering them since 2020), however, when it comes to their implementation in mainstream C++ compilers, only now things are becoming sort of usable with modules still being a challenge in more complex projects due to compiler bugs in the corner c…

Ya that is rather disingenuous, modules aren't ready, and likely won't be for another 5 years.

Also they are difficult to switch to, so I would expect very few established projects to bother.

Re: 21st Century C++

#214

Post by imtringued »

IshKebab wrote: post #204
Animats wrote: post #192

Earlier quoted context omitted.

> The C++ committee, including Bjarne Stroustrup, needs to accept that the language cannot be improved without breaking changes. The example in the article starts with "Wow, we have unordered maps now!" Just adding things modern languages have is nice, but doesn't fix the big problems. The basic problem is that you can't throw anything out. The mix of old and new stuff leads to obscure bugs. The new abstractions tend…

You absolutely can throw things out, and they have! Checked exceptions, `auto`, and breaking changes to operator== are the two I know of. There were also some minor breaking changes to comparison operators in C++20. They absolutely could say "in C++26 vector::operator[] will be checked" and add an `.at_unsafe()` method. They won't though because the whole standards committee still thinks that This Is Fine. In fact th…

"just get good" implies development processes that catch memory and safety bugs. Meaning what they are really saying between the lines is that the minimum cost of C++ development is really high.

Any C++ code without at least unit tests with 100% test coverage on with UB sanitizer etc, must be considered inherently defective and the developer should be flogged for his absurd levels of incompetence.

Then there is also the need for UB aware formal verification. You must define predicates/conditions under which your code is safe and all code paths that call this code must verifiably satisfy the predicates for all calls.

This means you're down to the statically verifiable subset of C++, which includes C++ that performs asserts at runtime, in case the condition cannot be verified at compile time.

How many C++ developers are trained in formal verification? As far as I am aware, they don't exist.

Any C++ developers reading this who haven't at least written unit tests with UB sanitizer for all of their production code should be ashamed of themselves. If this sounds harsh, remember that this is merely the logical conclusion of "just get good".

Re: 21st Century C++

#215

Post by imtringued »

logicchains wrote: post #201
nindalf wrote: post #172

Earlier quoted context omitted.

> And it's not clear if memory safety is the largest source of problems building software today. The Chromium team found that > Around 70% of our high severity security bugs are memory unsafety problems (that is, mistakes with C/C++ pointers). Half of those are use-after-free bugs. Chromium Security: Memory Safety ( https://www.chromium.org/Home/chromium-security/memory-safet... ) Microsoft found that > ~70% of the v…

Two of the biggest use cases for modern C++ are video games and HFT, where memory safety is of absolutely minimal importance (unless you're writing some shitty DRM/anticheat). I work in HFT using modern C++ and bugs related to memory safety are vanishingly rare compared to logic and performance bugs.

The importance of memory safety depends on whether your code must accept untrusted inputs or not.

Basically 99% of networked applications that don't talk to a trusted server and all OS level libraries fall under that category.

Your HFT code is most likely not connecting to an exchange that is interested in exploiting your trading code so the exploit surface is quite small. The only potential exploit involves other HFT algorithms trying to craft the order books into a malicious untrusted input to exploit your software.

Meanwhile if you are Google and write an android library, essentially all apps from the play store are out to get you.

Basically C++ code is like an infant that needs to be protected from strangers.

Re: 21st Century C++

#216

Post by imtringued »

jandrewrogers wrote: post #159
ninetyninenine wrote: post #157

21st century C++? AKA Rust?

Unfortunately, Rust is significantly less expressive than C++ and therefore is unlikely to replace it for high-performance systems code. As much as I don’t like C++, it is very powerful as a tool. The ability to express difficult low-level systems constructs and optimizations concisely and safely in the language are its killer feature. Once you know how to use it, other languages feel hobbled.

Most high performance code is vectorized and Rust is better at autovectorization and aliasing analysis than C++, so I'm not really seeing your point.

Having to drop down to intrinsics early is not a strength.

Re: 21st Century C++

#217

Post by imtringued »

jandrewrogers wrote: post #170
AlotOfReading wrote: post #163

Earlier quoted context omitted.

C++ doesn't allow you to express low level systems constructs concisely and safely though. You usually get neither. Look at the first example in the article, where the increment can overflow and cause UB despite that overflow having completely defined semantics at the hardware level. Fixing it requires either a custom addition function or C++26, another include, and add_sat(). I wouldn't consider either concise in a…

This assumes you are writing C++ in the most naive way possible. I’m sure some people do that but nothing requires it. The capabilities of a language are not defined by its worst programmers. Modern C++ allows you to swap out most features and behaviors of the language with your own implementations that make different guarantees. C++ is commonly used in high-assurance environments with extremely high performance requ…

DMA being a problem appears to be mostly a problem with a lack of identification of the data. If the shape of the data could be verified by the language runtime, instead of being an arbitrary stream of bytes whose meaning must be known by the recipient without any negotiation, this form of unsafety would disappear, since the receiving code simply needs to assert the schema, which could be as simple as checking a 32 bit integer.

Then all you need to do is also verify that the sending code adheres to the schema it specified.

This has very little to do with borrow checking. From the perspective of the borrow checker, a DMA call is no different from RPC or writing to a very wide pointer.

Re: 21st Century C++

#218

Post by TinkersW »

William_BB wrote: post #120
midnightclubbed wrote: post #111

Earlier quoted context omitted.

I have used auto liberally for 8+ years; maybe I'm accustomed to reading code containing it but I really can't think of it being a problem. I feel like auto increases readability, the only thing I dislike is that they didnt make it a reference by default. Where do you see difficult to track down performance/memory implications? Lambda comes to mind and maybe coroutines (yet to use them but guessing there may be some…

E.g. `std::ranges::for_each`, where lambda captures a bunch of variables by reference. Like I would hope the compiler optimizes this to be the same as a regular loop. But can I be certain, when compared to a good old for loop?

Just ban ranges lib, it is hot garbage anyway. The compilers are able to optimize lambdas fairly well nowadays(when inlined), I wouldn't be that concerned.

Re: 21st Century C++

#219

Post by TinkersW »

imron wrote: post #141
layer8 wrote: post #134

Earlier quoted context omitted.

It’s okay to be a few years behind the standard, the compilers tend to be as well.

Yeah, the issue is more that the perceived complexity means I’m less interested in investing time to catch it all back up

If you already used C++20 you aren't meaningfully behind, very little of interest has been introduced since then, and much of it isn't usable yet because of implementation issues.

Re: 21st Century C++

#220

Post by xigoi »

osmsucks wrote: post #209
DidYaWipe wrote: post #185

Let us know when C++ gets rid of the mess that is header files. Until then... YAWN.

The article does mention modules.

But it doesn’t mention that you can’t actually use modules without passing a bunch of random compiler flags and hoping that they work.
Post reply on HN