Live data from Hacker News

C++26 is done: ISO C++ standards meeting Trip Report

herbsutter.com

241–250 of 437 posts

Re: C++26 is done: ISO C++ standards meeting Trip Report

#241

Earlier quoted context omitted.

I wonder if C++ already has so much complexity, that it would actually be a good idea to ignore feature creep, and implement any feature with even the most remote use-case. It sounds (and probably is) insane. But if a feature breaks backwards compatibility, or can't be implemented in a way that non-negligibly affects compiler/IDE performance for codebases that ignore it, what's the issue? Specifically, what significa…

GCC and MSVC are pretty close. fyi, the tables on cppreference are rather outdated at this point. I made a more up-to-date, community-maintained site: https://cppstat.dev/?conformance=cpp20

Why does this need to access to all my repository just for generating a PR?

Re: C++26 is done: ISO C++ standards meeting Trip Report

#243
post #192

Earlier quoted context omitted.

What "endless crap that is just not that useful" has been added to Rust in your opinion?

returning "impl Trait". async/await unpin/pin/waker. catch_unwind. procedural macros. "auto impl trait for type that implements other trait". I understand some of these kinds of features are because Rust is Rust but it still feels useless to learn. I'm not following rust development since about 2 years so don't know what the newest things are.

RPIT (Return Position impl Trait) is Rust's spelling of existential types. That is, the compiler knows what we return (it has certain properties) but we didn't name it (we won't tell you what exactly it is), this can be for two reasons:

1. We didn't want to give the thing we're returning a name, it does have one, but we want that to be an implementation detail. In comparison the Rust stdlib's iterator functions all return specific named Iterators, e.g. the split method on strings returns a type actually named Split, with a remainder() function so you can stop and just get "everything else" from that function. That's an exhausting maintenance burden, if your library has some internal data structures whose values aren't really important or are unstable this allows you to duck out of all the extra documentation work, just say "It's an Iterator" with RPIT.

2. We literally cannot name this type, there's no agreed spelling for it. For example if you return a lambda its type does not have a name (in Rust or in C++) but this is a perfectly reasonable thing to want to do, just impossible without RPIT.

Blanket trait implementations ("auto impl trait for type that implements other trait") are an important convenience for conversions. If somebody wrote a From implementation then you get the analogous Into, TryFrom and even TryInto all provided because of this feature. You could write them, but it'd be tedious and error prone, so the machine does it for you.

Re: C++26 is done: ISO C++ standards meeting Trip Report

#245

Earlier quoted context omitted.

I wonder if you're fine with const, constexpr and volatile also being things. I mean, "const" really doesn't mean what one would naively think (that's what "constexpr" is actually for) and the semantics of "volatile" are also widely misunderstood.

Nope, not only is C++ const not a constant, C++ constexpr isn't a constant either, and C++ constinit isn't a constant, C++ consteval is closest, but it's only available for functions. const int a = 10; // Just an immutable variable named a constexpr int b = 20; // Still an immutable variable named b static constinit int c = 30; // Now it isn't even immutable For functions const says this function promises it doesn't…

groans See, and that's why I'm personally fine with [[indeterminate]], etc: all of this is already a finely-splitted hairy mess and I'd rather not see even more keywords introduced if we can just use attributes instead.

And yeah, it would probably be nice to also have some sane intrinsics to provide memory_order_consume semantics... but what can you do.

Re: C++26 is done: ISO C++ standards meeting Trip Report

#246

Earlier quoted context omitted.

Also, having one standard packaging format and registry doesn't preclude having alternatives for special use cases. There should be a happy path for the majority of C++ use cases so that I can make a package, publish it and consume other people's packages. Anyone who wants to leave that happy path can do so freely at their own risk. The important thing is to get one system blessed as The C++ Package Format by the sta…

In the Linux world and even Haiku, there is a standard package dependacy format, so dependencies aren’t really a problem. Even OSX has Homebrew. Windows is the odd man out.

Are you talking about system/application dependencies for installed applications or programming dependencies like compiled libraries and header files?

Re: C++26 is done: ISO C++ standards meeting Trip Report

#247

The "erroneous behavior" redefinition for reads of uninitialized variables is really interesting: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p27... It does have a runtime cost. There's an attribute to force undefined behavior on read again and avoid the cost: int x [[indeterminate]]; std::cin >> x;

On a quick read of the paper, I see two surprising things:

1. If there’s no initializer and various conditions are met, then “the bytes have erroneous values, where each value is determined by the implementation independently of the state of the program.

What does “independently” mean? Are we talking about all zeros? Is the implementation not permitted to use whatever arbitrary value was in memory? Why not?

2. What’s up with [[indeterminate]]? I would expect “indeterminate” to mean that the variable has a value that happens to be arbitrary (and may contain sensitive data, etc), not that it turns back into actual UB.

Re: C++26 is done: ISO C++ standards meeting Trip Report

#248

Earlier quoted context omitted.

> I have several times built my own system to do just that when it wasn't even my main job. Doesn't take more than a couple of days. Really? I'd love a link to even something that works as a toy project > Bazel is certainly not the solution; it's arguably closer to being the problem. The worst build system I have ever seen was Bazel-based. I agree

It usually ends up somewhat non-generic, with project-specific decisions hardcoded rather than specified in a config file. I usually make it so that it's fully integrated with wherever we store artifacts (for CAS), source (to download specific revisions as needed), remote running (which depending on the shop can be local, docker, ssh, kubernetes, ...), GDB, IDEs... All that stuff takes more work for a truly generic s…

This is all great, but it doesn’t sound simple or like 200 lines of code.

Re: C++26 is done: ISO C++ standards meeting Trip Report

#249
post #112

Earlier quoted context omitted.

Well, there has been a long campaign against manual memory management - well before Rust was a thing. And along with that, a push for less use of raw pointers, less index loops etc. - all measures which, when adopted, reduce memory safety hazards significantly. Following the Core Guideliness also helps, as does using span's. Compiler warnings has improved, as has static analysis, also in a long process preceding Rust…

>Following the Core Guideliness also helps Yes, this what Stroustrup said and it makes me laugh. IIRC he phrased with a more of a 'we had safety before Rust' attitude. It also misses the point, safety shouldn't be opt-in or require memorising a rulebook. If safety is that easy in C++ why is everyone still sticking their hand in the shredder?

You're "moving the goal posts" of this thread. Safety has mattered - in C++ and in other languages as well, e.g. with MISRA C.

As for the Core Guidelines - most of them are not about safety; and - they are not to be memorized, but a resource to consult when relevant, and something to base static analysis on.

Re: C++26 is done: ISO C++ standards meeting Trip Report

#250
post #7

Biggest open question is whether the small changes to the module system in this standard will actually lead to more widespread adoption

The best thing the C++ WG could do is to spend an entire release cycle working on modules and packaging. It's nice to have new features, but what is really killing C++ is Cargo. I don't think a new generation of developers are going to be inspired to learn a language where you can't simply `cargo add` whatever you need and instead have to go through hell to use a dependency.

100% agree this is something that would have immediate, high value impact.

The fact that building C++ is this opaque process defined in 15 different ways via make, autoconf, automake, cmake, ninja, with 50 other toolchains is something that continues to create a barrier to entry.

I still remember the horrors of trying to compile c++ in 2004 on windows without anything besides borland...

Standardizing the build system and toolchain needs to happen. It's a hard problem that needs to be solved.

Post reply on HN