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

201–210 of 281 posts

Re: 21st Century C++

#201

Post by logicchains »

nindalf wrote: post #172
mempko wrote: post #80

Earlier quoted context omitted.

What are you talking about, the language gets better with each release. Using C++ today is a hell of a lot better than even 10 years ago. It seems like people hold "memory safety" as the most important thing a language can have. I completely disagree. It turns out you can build awesome and useful software without memory safety. And it's not clear if memory safety is the largest source of problems building software to…

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

Re: 21st Century C++

#202

Post by 01100011 »

xyproto wrote: post #95
imron wrote: post #94

I want to love C++. Over my career I’ve written hundreds of thousands of lines of it. But keeping up with it is time consuming and more and more I find myself reaching for other languages.

I went from being curious about C++, to hating C++, to wanting to love it, to being fine with it, to using it for work for 5+ years, to abandoning it and finally to want to use it for game development, maybe. It's the circle of life.

It's my job and career(well, C and C++) but I often try to avoid C++. Whenever I use it(usually writing tests) I go through this cycle of re-learning some cool tricks, trying to apply them, realizing they won't do what I want or the syntax to do it is awkward and more work than the dumb way, and I end up hating C++ and feeling burned yet again.

Re: 21st Century C++

#203

Post by immibis »

richard_todd wrote: post #166
fooker wrote: post #151

Earlier quoted context omitted.

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

It's bottom-up vs top-down design.

Re: 21st Century C++

#204

Post by IshKebab »

Animats wrote: post #192
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.…

> 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 the number of "just get good" people in the committee has probably increased - everyone with any brains has run away to Rust (and maybe Zig).

Re: 21st Century C++

#205

Post by bobnamob »

3vidence wrote: post #126
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 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

Re: 21st Century C++

#206

Post by simoncion »

thbb123 wrote: post #83
IshKebab wrote: post #48

Earlier quoted context omitted.

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.

I don't know about go, but java is pathetic. I have 30 years old c++ programs that work just fine. However, an application that I had written to be backward compatible with java 1.4, 15 years ago, cannot be compiled today. And I had to make major changes to have it run on anything past java 8, ~10 years ago, I believe.

Compared to C++ (or even Erlang), Go is pretty bad.

$DAYJOB got burned badly twice on breaking Go behavioral changes delivered in non-major versions, so management created a group to carefully review Go releases and approve them for use.

All too often, Google's justification for breaking things is "Well, we checked the code in Google, and publicly available on Github, and this change wouldn't affect TOO many people, so we're doing it because it's convenient for us.".

Re: 21st Century C++

#207

Post by simoncion »

ivan_gammel wrote: post #180
bigstrat2003 wrote: post #161

Earlier quoted context omitted.

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 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-breaking changes in minor versions.

Re: 21st Century C++

#208

Post by saagarjha »

WalterBright wrote: post #177
mempko wrote: post #80

Earlier quoted context omitted.

What are you talking about, the language gets better with each release. Using C++ today is a hell of a lot better than even 10 years ago. It seems like people hold "memory safety" as the most important thing a language can have. I completely disagree. It turns out you can build awesome and useful software without memory safety. And it's not clear if memory safety is the largest source of problems building software to…

The top memory safety bugs in shipped code for C and C++ are out of bounds array indexing.

Are you sure? I generally see more use-after-free and other lifetime issues.

Re: 21st Century C++

#210

Post by saagarjha »

tialaramex wrote: post #36
bluGill wrote: post #23

Earlier quoted context omitted.

Profiles will not provide perfect memory safety, but they go a long way to making things better. I have 10 million lines of C++. A breaking change (doesn't matter if you call it new C++ or Rust) would cost over a billion dollars - that is not happening. Which is to say I cannot use your perfect solution, I have to deal with what I have today and if profiles can make my code better without costing a full rewrite then…

Changes which re-define the language to have less UB will help you if you want safety/ correctness and are willing to do some work to bring that code to the newer language. An example would be the initialization rules in (draft) C++ 26. Historically C++ was OK with you just forgetting to initialize a primitive before using it, that's Undefined Behaviour in the language so... if that happens too bad all bets are off.…

This seems bad actually.
Post reply on HN