Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

herbsutter.com

Post reply on HN
Print view View original

51–60 of 437 posts

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

#51

Post by light_hue_1 »

ho_schi wrote: post #27
zarzavat wrote: post #7

Earlier quoted context omitted.

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.

I’m still surprised how people ignore Meson. Please test it :) https://mesonbuild.com/ And Mesons awesome dependency handling: https://mesonbuild.com/Dependencies.html https://mesonbuild.com/Using-the-WrapDB.html#using-the-wrapd... https://nibblestew.blogspot.com/2026/02/c-and-c-dependencies... I suffered with Java from Any, Maven and Gradle (the oldest is the the best). After reading about GNU Autotools I was wonder…

Meson merges the crappy state of C/C++ tooling with something like Cargo in the worst way possible: by forcing you to handle the complexity of both. Nothing about Meson is simple, unless you're using it in Rust, in which case you're better off with Cargo.

In C++ you don't get lockfiles, you don't get automatic dependency install, you don't get local dependencies, there's no package registry, no version support, no dependency-wide feature flags (this is an incoherent mess in Meson), no notion of workspaces, etc.

Compared to Cargo, Meson isn't even in the same galaxy. And even compared to CMake, Meson is yet another incompatible incremental "improvement" that offers basically nothing other than cute syntax (which in an era when AI writes all of your build system anyway, doesn't even matter). I'd much rather just pick CMake and move on.

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

#52

Post by vlovich123 »

saghm wrote: post #45
zarzavat wrote: post #7

Earlier quoted context omitted.

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.

To me, the most important feature of Cargo isn't even the dependency management but that I don't ever need to tell it which files to compile or where to find them. The fact that it knows to look for lib.rs or main.rs in src and then recursively find all my other modules without me needing to specify targets or anything like that is a killer feature on its own IMO. Over the past couple of years I've tried to clone and…

For me the lack of dependency hell until I hit a c/c++ component somewhere in the build is the real winner.

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

#53

Post by tialaramex »

mgaunard wrote: post #25
luka598 wrote: post #13

Earlier quoted context omitted.

Agreed, arcane cmake configs and or bash build scripts are genuinely off-putting. Also cpp "equivalents" of cargo which afaik are conan and vcpkg are not default and required much more configuring in comparison with cargo. Atleast this was my experience few years ago.

It's fundamentally different; Rust entirely rejects the notion of a stable ABI, and simply builds everything from source. C and C++ are usually stuck in that antiquated thinking that you should build a module, package it into some libraries, install/export the library binaries and associated assets, then import those in other projects. That makes everything slow, inefficient, and widely dangerous. There are of course…

It's not true that Rust rejects "the notion of a stable ABI". Rust rejects the C++ solution of freeze everything and hope because it's a disaster, it's less stable than some customers hoped and yet it's frozen in practice so it disappoints others. Rust says an ABI should be a promise by a developer, the way its existing C ABI is, that you can explicitly make or not make.

Rust is interested in having a properly thought out ABI that's nicer than the C ABI which it supports today. It'd be nice to have say, ABI for slices for example. But "freeze everything and hope" isn't that, it means every user of your language into the unforeseeable future has to pay for every mistake made by the language designers, and that's already a sizeable price for C++ to pay, "ABI: Now or never" spells some of that out and we don't want to join them.

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

#54

Post by quotemstr »

addaon wrote: post #17
suby wrote: post #11

I am somewhat dismayed that contracts were accepted. It feels like piling on ever more complexity to a language which has already surpassed its complexity budget, and given that the feature comes with its own set of footguns I'm not sure that it is justified. Here's a quote from Bjarne, > So go back about one year, and we could vote about it before it got into the standard, and some of us voted no. Now we have a much…

I can’t speak to the C++ contract design — it’s possible bad choices were made. But contracts in general are absolutely exactly what C++ needs for the next step of its evolution. Programming languages used for correct-by-design software (Ada, C++, Rust) need to enable deep integration with proof assistants to allow showing arbitrary properties statically instead of via testing, and contracts are /the/ key part of tha…

But why? You can do everything contracts do in your own code, yes? Why make it a language feature? I'm not against growing the language, but I don't see the necessity of this specific feature having new syntax.

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

#55

Post by steveklabnik »

dislikedopinion wrote: post #24
bluGill wrote: post #20

Earlier quoted context omitted.

The people who did contracts are aware of ada/spark and some have experience using it. Only time will tell if it works in c++ but they at least did all they could to give it a chance. Note that this is not the end of contrats. This is a minimun viable start that they intend to add to but the missing parts are more complex.

Might be the case that Ada folks successfully got a bad version of contracts not amenable for compile-time checking into C++, to undermine the competition. Time might tell.

This is some pretty major conspiracy thinking, and would need some serious evidence. Do you have any?

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

#56

Post by usrnm »

porise wrote: post #23

I don't care until they stop pretending Unicode doesn't exist.

What are you talking about, there is actually too much unicode awareness in C++. Unicode is not the same thing as utf-8. And, frankly, no language does it right, I'm not even sure "right" exists with Unicode

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

#57

Post by chrisaycock »

std::execution is very interesting, but will be difficult to get started with, as cautioned by Sutter. This HPC Wire article demonstrates how to use standard C++ to benefit from asynchronously parallel computation on both CUDA and MPI:

https://www.hpcwire.com/2022/12/05/new-c-sender-library-enab...

Overlapping communication and computation has been a common technique for decades in high-performance computing to "hide latency", which leads to better scaling. Now standard C++ can be used to express parallel algorithms without tying to a specific scheduler.

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

#58

Post by stackghost »

dislikedopinion wrote: post #24
bluGill wrote: post #20

Earlier quoted context omitted.

The people who did contracts are aware of ada/spark and some have experience using it. Only time will tell if it works in c++ but they at least did all they could to give it a chance. Note that this is not the end of contrats. This is a minimun viable start that they intend to add to but the missing parts are more complex.

Might be the case that Ada folks successfully got a bad version of contracts not amenable for compile-time checking into C++, to undermine the competition. Time might tell.

I strongly doubt that C++ is what's standing in the way of Ada being popular.

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

#59

Post by jandrewrogers »

quotemstr wrote: post #54
addaon wrote: post #17

Earlier quoted context omitted.

I can’t speak to the C++ contract design — it’s possible bad choices were made. But contracts in general are absolutely exactly what C++ needs for the next step of its evolution. Programming languages used for correct-by-design software (Ada, C++, Rust) need to enable deep integration with proof assistants to allow showing arbitrary properties statically instead of via testing, and contracts are /the/ key part of tha…

But why? You can do everything contracts do in your own code, yes? Why make it a language feature? I'm not against growing the language, but I don't see the necessity of this specific feature having new syntax.

DYI contracts don't compose when mixing code using different DYI implementations. Some aspects of contracts have global semantics.

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

#60

Post by jevndev »

quotemstr wrote: post #54
addaon wrote: post #17

Earlier quoted context omitted.

I can’t speak to the C++ contract design — it’s possible bad choices were made. But contracts in general are absolutely exactly what C++ needs for the next step of its evolution. Programming languages used for correct-by-design software (Ada, C++, Rust) need to enable deep integration with proof assistants to allow showing arbitrary properties statically instead of via testing, and contracts are /the/ key part of tha…

But why? You can do everything contracts do in your own code, yes? Why make it a language feature? I'm not against growing the language, but I don't see the necessity of this specific feature having new syntax.

The common argument for a language feature is for standardization of how you express invariants and pre/post conditions so that tools (mostly static tooling and optimizers) can be designed around them.

But like modules and concepts the committee has opted for staggered implementation. What we have now is effectively syntax sugar over what could already be done with asserts, well designed types and exceptions.

Post reply on HN