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

161–170 of 281 posts

Re: 21st Century C++

#161

Post by bigstrat2003 »

IshKebab wrote: post #48
htfy96 wrote: post #29

Earlier quoted context omitted.

While I sort of agree on the complaint, personally I think the best spot of C++ in this ecosystem is still on great backward-compatibility and marginal safety improvements. I would never expect our 10M+ LOC performance-sensive C++ code base to be formally memory safe, but so far only C++ allowed us to maintain it for 15 years with partial refactor and minimal upgrade pain.

I think at least Go and Java have as good backwards compatibility as C++. Most languages take backwards compatibility very seriously. It was quite a surprise to me when Python broke so much code with the 3.12 release. I think it's the exception.

Java has had shit backwards compatibility for as long as I have had to deal with it. Maybe it's better now, but I have not forgotten the days of "you have to use exactly Java 1.4.15 or this app won't work"... with four different apps that each need their own different version of the JRE or they break. The only thing that finally made Java apps tolerable to support was the rise of app virtualization solutions. Before that, it was a nightmare and Java was justly known as "the devil's software" to everyone who had to support it.

Re: 21st Century C++

#162

Post by steveklabnik »

AnonC wrote: post #160

Tangential question: is there a Rust equivalent for the book “The Design and Evolution of C++”?

There is not.

I have often thought about writing something vaguely similar. We’ll see if I ever do. It wouldn’t be the same because I don’t hold the same position Bjarne did in the early days, but I am very interested in Rust history, and want to preserve it. It wouldn’t be from my perspective rather than from the creator’s perspective.

I did give a talk one time on Rust’s history. It was originally at FOSDEM, but there was an issue with the recording. The ACM graciously asked me to do it again to get it down on video https://dl.acm.org/doi/10.1145/2959689.2960081

Re: 21st Century C++

#163

Post by AlotOfReading »

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.

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 program that doesn't include all of std.

Re: 21st Century C++

#164

Post by cylemons »

zozbot234 wrote: post #81
bluGill wrote: post #76

Earlier quoted context omitted.

That is one of of the three. It isn't really backward compatible because to take adventage of it you need to write\change a lot of code. a nice attempt but I have millions of lines of c++ that isn't going away-

"C++ isn't really backward compatible with C because to take advantage of its classes and templates you need to change so much code..."

But these are not safety features

Re: 21st Century C++

#165

Post by munificent »

steveklabnik wrote: post #162
AnonC wrote: post #160

Tangential question: is there a Rust equivalent for the book “The Design and Evolution of C++”?

There is not. I have often thought about writing something vaguely similar. We’ll see if I ever do. It wouldn’t be the same because I don’t hold the same position Bjarne did in the early days, but I am very interested in Rust history, and want to preserve it. It wouldn’t be from my perspective rather than from the creator’s perspective. I did give a talk one time on Rust’s history. It was originally at FOSDEM, but th…

I would 100% buy a hardback gold embossed version of this book.

Re: 21st Century C++

#166

Post by richard_todd »

fooker wrote: post #151
coffeeaddict1 wrote: post #18

The C++ Core Guidelines have existed for nearly 10 years now. Despite this, not a single implementation in any of the three major compilers exists that can enforce them. Profiles, which Bjarne et al have had years to work on, will not provide memory safety[0]. The C++ committee, including Bjarne Stroustrup, needs to accept that the language cannot be improved without breaking changes. However, it's already too late.…

>Despite this, not a single implementation in any of the three major compilers exists that can enforce them Because no one wants it enough to implement it.

I feel like a few decades ago, standards intended to standardize best practices and popular features from compilers in the field. Dreaming up standards that nobody has implemented, like what seems to happen these days, just seems crazy to me.

Re: 21st Century C++

#167

Post by mempko »

justanotheratom wrote: post #154
mempko wrote: post #144

Earlier quoted context omitted.

They don't have to. The subset depends on the job! That's the beauty and power of C++. That's why we have projects written in it in all domains. From websites to spaceships and Mars rovers.

yes, and you will tell me exactly what subset and coding convention "makes sense" for this domain, and you will give your reasoning too. And I will give my arguments, and on and on it goes. teams have broken up over this. A well-designed language is one in which there are very few different ways of doing the same thing. And C++ is definitely not that.

Why would a well designed language have only one or few ways to do the same thing? Seems rather arbitrary. I like when I have many ways to do the same thing.

Imagine if you told a writer or poet that English is bad because there is more than one way to say the same thing...

Programming languages are for people more than machines. Machines are happy with microcode.

Re: 21st Century C++

#168

Post by codr7 »

mr_00ff00 wrote: post #108
codr7 wrote: post #97

Earlier quoted context omitted.

I've been writing C++ since 1996-ish. Less and less, for sure. Nothing the past few years. They killed it.

If you only read HN, you would think C++ died years ago. As someone who worked in HFT, C++ is very much alive and new projects continue to be created in it simply because of the sheer of amount of experts in it. (For better or for worse)

The fact that we don't have a viable alternative yet doesn't exactly mean that the language is in good shape.

Re: 21st Century C++

#169

Post by AnonC »

steveklabnik wrote: post #162
AnonC wrote: post #160

Tangential question: is there a Rust equivalent for the book “The Design and Evolution of C++”?

There is not. I have often thought about writing something vaguely similar. We’ll see if I ever do. It wouldn’t be the same because I don’t hold the same position Bjarne did in the early days, but I am very interested in Rust history, and want to preserve it. It wouldn’t be from my perspective rather than from the creator’s perspective. I did give a talk one time on Rust’s history. It was originally at FOSDEM, but th…

Thank you. It would be interesting to read the history, including the design decisions, the influences (and distractions), the trade offs, etc.

When I read “The Design and Evolution of C++”, it gave me a better understanding of the language.

Re: 21st Century C++

#170

Post by jandrewrogers »

AlotOfReading wrote: post #163
jandrewrogers wrote: post #159

Earlier quoted context omitted.

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.

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 requirements, and it remains the most effective language for these purposes because you can completely replace most of the language with something that makes the safety guarantees you require. This is rather important. For example, userspace DMA is idiomatic in e.g. high-performance databases kernels; handling this is much safer in C++ than Rust. In C++, you can trivially write elegant primitives that completely hide the unusual safety model. In Rust, you have to write a lot of ugly unsafe code to make this work at all because userspace DMA isn’t compatible with a borrow checker. There can always be multiple mutable references to memory but it is not knowable at compile-time, safety of an operation can only be arbitrated at runtime.

Of course, it is still incumbent on the developer to use the language competently in all cases.

Post reply on HN