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

241–250 of 281 posts

Re: 21st Century C++

#241

Post by steveklabnik »

ephaeton wrote: post #233
steveklabnik wrote: post #230

Earlier quoted context omitted.

I don’t understand what you’re trying to say, could you elaborate?

I'm sharing sentiment. C++ feels like a language of bean counters. Rust feels like a language of bean counters. A lot of C++ folks I know went over to rust. They were happy with C++ and it was the best thing since sliced bread. They are now happy with rust and it is the best thing since sliced bread. To me, languages have a, let's call it 'taste' for the lack of better word off the top of my head. It's that combining…

> C++ feels like a language of bean counters.

> Rust feels like a language of bean counters.

Gotcha! I just didn't make the connection, when I read your comment I thought "what does a list of C++ features + the idea that people left it because they didn't like where it's going mean that the two languages are the same?"

I wasn't interested in arguing either, I was just trying to understand what you meant, and now I do. Thank you for sharing.

Re: 21st Century C++

#242

Post by ephaeton »

IshKebab wrote: post #240
ephaeton wrote: post #233

Earlier quoted context omitted.

I'm sharing sentiment. C++ feels like a language of bean counters. Rust feels like a language of bean counters. A lot of C++ folks I know went over to rust. They were happy with C++ and it was the best thing since sliced bread. They are now happy with rust and it is the best thing since sliced bread. To me, languages have a, let's call it 'taste' for the lack of better word off the top of my head. It's that combining…

Rust was definitely created as an alternative to C++, but I don't really get your criticism. Unless you're just saying you don't like robust languages with very strong type systems or something? Rust wasn't designed by committee.

To me, Rust feels as if it had sprung from the same mind. Or in the case of C++, set of minds. Who have a common mindset. I sadly don't critize rust's general design choices constructively. It's more of a public realization, '"C++ mind-set compatible" might just be the quality to describe the specific aroma I dislike in this melange".

I'm fine with robust languages with very strong type systems, I think. Are Haskell, ML, F#, Scala in this set? Robust and very strongly typed enough? I don't dislike their taste, even though I think I've had enough scala, specifically, for this life time. If these aren't in the set you're thinking of, I'd like to know what makes up that set for you.

Re: 21st Century C++

#243

Post by SunlitCat »

ephaeton wrote: post #231

loving he goes 'int main() { ... }' and never returns an int from it. Even better: without extra error / warning flags the compiler will just eat this and generate some code from it, returning ... yeah. Your guess is probably better than mine. If the uber-bean counter, herald of the language of bean counters demonstrate unwillingness to count beans, maybe the beans are better counted in another way.

To me, it's kinda funny that he starts with

> using namespace std

something you get told not to do easily! :D

Re: 21st Century C++

#244

Post by tialaramex »

amluto wrote: post #238
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…

I find the unordered_map example rather amusing. C++’s unordered_map is, somewhat infamously, specified in an unwise way. One basically cannot implement it with a modern, high performance hash table for at least two reasons: 1. unordered_map requires some bizarre and not widely useful abilities that mostly preclude hash tables with probing: https://stackoverflow.com/questions/21518704/how-does-c-stl-... 2. unordered_…

Like std::vector, std::unordered_map also doesn't do a good job on reservation, I've never been entirely sure what to make of that - did they not care? Or is there some subtle reason why what they're doing made sense on the 1980s computers where this was conceived?

For std::vector it apparently just didn't occur to C++ people to provide the correct API, Bjarne Stroustrup claims the only reason to use a reservation API is to prevent reference and iterator invalidation. -shrug-

[std::unordered_map was standardised this century, but, the thing standardised isn't something you'd design this century, it's the data structure you'd have been shown in an undergraduate Data Structures class 40 years ago.]

Re: 21st Century C++

#245

Post by amluto »

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…

> auto

It took me several reads to figure out that you probably meant ‘auto’ the storage class specifier. And now I’m wondering whether this was ever anything but a no-op in C++.

Re: 21st Century C++

#246

Post by gHosts »

wakawaka28 wrote: post #69
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.…

Enforcing style guidelines seems like an issue that should be tackled by non-compiler tools. It is hard enough to make a compiler without rolling in a ton of subjective standards (yes, the core guidelines are subjective!). There are lots of other tools that have partial support for detecting and even fixing code according to various guidelines.

It's part of a compiler ecosystem. ie. The front end is shared.

See clang-tidy and clang analyzer for example.

ps: That's what I like most about the core guidelines, they are trying very hard to stick to guidelines (not rules) that pretty much uncontroversially make things safer _and_ can be checked automatically.

They're explicitly walking away from bikeshed paintings like naming conventions and formatting.

Re: 21st Century C++

#247

Post by gHosts »

bboygravity wrote: post #187
mr_00ff00 wrote: post #108

Earlier quoted context omitted.

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)

Can confirm pretty much the entire embedded systems world uses either C or C++. That's probably most devices in the world.

It used to be C++ would be the last choice for embedded...

Modern C++ with constexpr and friends and the massive work and cunning they have put into avoiding template bloat....

...C++ is now my first choice for embedded.

Re: 21st Century C++

#248

Post by 3vidence »

bobnamob wrote: post #205
3vidence wrote: post #126

Earlier quoted context omitted.

Can also confirm c++ is alive and well at FAANG. Might still be the most popular language for most new projects.

* for some values of FAANG C++ has been dead and effectively banned at amzn for years. Only very specific (robotics and ML generally) projects get exemptions. Rust is big and only getting bigger

Fair! I would say people would be surprised to learn pretty much every large AI project is mostly c++ because of its interop with python.

Some FAANGs focus on AI more than others.

Re: 21st Century C++

#249

Post by amluto »

tialaramex wrote: post #244
amluto wrote: post #238

Earlier quoted context omitted.

I find the unordered_map example rather amusing. C++’s unordered_map is, somewhat infamously, specified in an unwise way. One basically cannot implement it with a modern, high performance hash table for at least two reasons: 1. unordered_map requires some bizarre and not widely useful abilities that mostly preclude hash tables with probing: https://stackoverflow.com/questions/21518704/how-does-c-stl-... 2. unordered_…

Like std::vector, std::unordered_map also doesn't do a good job on reservation, I've never been entirely sure what to make of that - did they not care? Or is there some subtle reason why what they're doing made sense on the 1980s computers where this was conceived? For std::vector it apparently just didn't occur to C++ people to provide the correct API, Bjarne Stroustrup claims the only reason to use a reservation AP…

> For std::vector it apparently just didn't occur to C++ people to provide the correct API, Bjarne Stroustrup claims the only reason to use a reservation API is to prevent reference and iterator invalidation. -shrug-

Do you mean something like vector::reserve_at_least()? I suppose that, if you don’t care about performance, you might not need it.

FWIW, I find myself mostly using reserve in cases where I know what I intend to append and when I will be done appending to that vector forever afterwards.

Re: 21st Century C++

#250

Post by imron »

jandrewrogers wrote: post #194
jpc0 wrote: post #190

Earlier quoted context omitted.

To be fair std::ranges seems like the biggest mistake the committee allowed into the language recently. Effectively other than for rewriting older iterators based algorithms to using new ranges iterators I just don't use std::ranges... Likely the compiler cannot optimise it as well (yet) and all the edge cases are not workes out yet. I also find it to be quite difficult to reason about vs older iterator based algorit…

Yeah, the std::ranges implementation is a bit of a mess. The inability to start clean without regard for backward compatibility reasons limits what is possible. I think most people see how you could implement comparable functionality with nicer properties from a clean sheet of paper. It is the curse of being an old language.

There are sane approaches to dealing with this - e.g. epochs.

This wasn’t proven by the time c++11 was ready, but for c++20 and beyond it’s a shame they didn’t go with this.

Post reply on HN