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

191–200 of 281 posts

Re: 21st Century C++

#191

Post by jandrewrogers »

AlotOfReading wrote: post #173
jandrewrogers wrote: post #170

Earlier quoted context omitted.

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…

The capabilities of a language are not defined by its worst programmers. Is the implication here that Bjarne is a bad C++ developer? If the person in charge of the EWG fails "to use the language competently in all cases", what hope is there for the rest of us mere mortals? For what it's worth, unsafe Rust is safer than C++. There's very little UB to explode your carefully crafted implementations. Safe rust of course…

UB is a feature of the standard, not the implementation. Many of those behaviors can be defined. Modern C++ conveniently allows you to replace many of the bits that have UB, per standard, with your own bits with defined behavior with zero overhead. This was not always the case. You aren’t dependent on the compiler implementor. The ability to consistently do this transparently became practical around C++17 IMO. The C++ standard library is in many regards obsolete and many orgs treat it that way.

I never suggested that C++ was “a form of high level assembly”. I’ve written enough assembly and C to know better; you lose a bit of precision with C++. But now I can define (or not) the behavior I want in a way that is largely transparent. This has been a brilliant change to the language.

If you have a foundational library that makes different and/or explicit guarantees than std, it is pretty easy to police that in a code base with automation. Everyone doing high-performance and/or high-assurance systems is dragging in few if any dependencies, so this is practical. The kinds of things that C++ is really good at for new code are the kinds of things where this is what you would do regardless.

Developers don’t even have to be hardware experts, they just have to not use std for most things. That is a pretty low barrier. And std is a mess with the albatross of legacy support. Reimagined C++20 native “standard” libraries are much, much cleaner and safer (and faster).

Legacy C++ code bases aren’t going to be rewritten in a new language. New C++ code bases can take advantage of alternative foundations that ignore std and many do. Most things should not be written in C++, but for some things C++ is unmatched currently and safer in practice than is often suggested with basic hygiene.

Re: 21st Century C++

#192

Post by Animats »

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 to leak raw pointers, so that old stuff can be called.

C++ is almost unique in having hiding ("abstraction") without safety. That's the big problem.

Re: 21st Century C++

#193

Post by Animats »

bluGill wrote: post #37
zozbot234 wrote: post #26

Earlier quoted context omitted.

> Profiles, which Bjarne et al have had years to work on, will not provide memory safety While I agree with this in a general sense, I think it ought to be quite possible to come up with a "profile" spec that's simply meant to enforce the language restriction/subsetting part of Safe C++ - meaning only the essentials of the safety checking mechanism, including the use of the borrow checker. Of course, this would not b…

I have seen 3 different safe c++ proposals (most are not papers yet, but they are serious efforts to show what safe c++ could look like). However there is a tradeoff here. the full bower checker in C++ approach is incompatible with all current C+++ and so adopting it is about as difficult is rewriting all your code in some other language. The other proposals are not as safe, but have different levels of you can use t…

I've seen maybe twice that many. Did one myself once. It's possible to make forward progress, but to get any real safety you have to prohibit some things.

Re: 21st Century C++

#194

Post by jandrewrogers »

jpc0 wrote: post #190
William_BB wrote: post #120

Earlier quoted context omitted.

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?

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.

Re: 21st Century C++

#195

Post by throwaway2037 »

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?

Did you try the two version in Godbolt?

Re: 21st Century C++

#196

Post by chikere232 »

codr7 wrote: post #168
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)

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

It just means it's in the best shape of any of the languages in it's domain

Re: 21st Century C++

#197

Post by tsimionescu »

jpc0 wrote: post #179
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…

> Around 70% of our high severity security bugs are memory unsafety problems > ~70% of the vulnerabilities Microsoft assigns a CVE > 76% of vulnerabilities What is the difference between the first two (emphasis added) and what you said? Just as a thought experiment... If I measure a single factor in exclusion to all others I can also find whatever I want in any set of data. Now your point may be valid but it is not w…

This whole concept that code should be architected as "libraries" and "userspace" is such a C++ism.

It's a really weird concept that probably comes only from having this extremely complex language where even the designers expect some parts of it are too weird for "normal programmers". But then they imagine some advanced class of programmer, the "library programmers", who can deal with such complexity.

The more modern way of designing software is to stick to the YAGNI principle: design your code to be simple and straightforward, and only extract out datastructures into separate libraries if and when they prove to be needed.

Not to mention, the position that shared ownership should just not exist at all is self-evidently absurd. The lifetime of an object can very well be a dynamic property of your program, and a concurrent one. A language that lacks std::shared_ptr / Arc is simply not a complete language, there will be algorithms that you just can't express.

Re: 21st Century C++

#198

Post by astrobe_ »

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.

You don't have to "keep up with it", if by this you mean what I think you mean.

You don't have to use features. Instead, when you have a (language) problem to solve or something you'd like to have, you look into the features of the language.

Knowing they exist beforehand is better but is the hard part, because "deep" C++ is so hermetic that it is difficult to understand a feature when you have no idea which problem it is trying to solve.

Re: 21st Century C++

#199

Post by 01100011 »

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 mean, right from Bjarne's mouth:

> I used the from_range argument to tell the compiler and a human reader that a range is used, rather than other possible ways of initializing the vector. I would have preferred to use the logically minimal vector{m} but the standards committee decided that requiring from_range would be a help to many.

Oh so I have to remember from_range and can't do the obvious thing? Great. One more thing to distract me from solving the actual problem I'm working on.

What exactly is wrong with the C++ community that blinds them to this sort of thing? I should be able to write performant, low-level code leveraging batteries-included algorithms effortlessly. This is 2025 people.

Re: 21st Century C++

#200

Post by 01100011 »

astrobe_ wrote: post #198
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.

You don't have to "keep up with it", if by this you mean what I think you mean. You don't have to use features. Instead, when you have a (language) problem to solve or something you'd like to have, you look into the features of the language. Knowing they exist beforehand is better but is the hard part, because "deep" C++ is so hermetic that it is difficult to understand a feature when you have no idea which problem i…

Wrong. Most programmers spend tremendous amounts of time reading and maintaining someone else's code. You absolutely have to keep up with it.
Post reply on HN