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

101–110 of 437 posts

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

#101

Post by PerryStyle »

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 is indeed nice, but has very poor support for GPU compilation compared to CMake. I've had a lot of success adopting the practices described in this talk, https://www.youtube.com/watch?v=K5Kg8TOTKjU. I thought I knew a lot of CMake, but file sets definitely make things a lot simpler.

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

#102

Post by gmueckl »

ghighi7878 wrote: post #98
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…

Just because Bjarne thinks the feature is bad doesnt mean it is bad. He can be wrong. The point is, most peoppe disagree with him, and so a lot of peoppe do think it is good.

There have been several talks about contracts and the somewhat hidden complexities in them. C++ contracts are not like what you'd initally expect. Compiler switches can totally alter how contracts behave from getting omitted to reporting failures to aborting the program. There is also an optional global callback for when a contract check fails.

Different TUs can be compiled with different settings for the contract behavior. But can they be binary compatible? In general, no. If a function is declared in-line in a header, the comoiler may have generated two different versions with different contract behaviors, which violates ODR.

What happens if the contract check calls a helper function that throws an exception?

The whole things is really, really complex and I don't assume that I understand it properly. But I can see that there are some valid concerns against the feature as standardized and that makes me side with the opposition here: this was not baked enough yet

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

#103

Post by Blackthorn »

leni536 wrote: post #90
usrnm wrote: post #56

Earlier quoted context omitted.

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

Too much unicode in standard C++? Where?

c++20's u8strings took a giant steaming dump on a number of existing projects, to the point that compiler flags had to be introduced to disable the feature just so c++20 would work with existing codebases. Granted that's utf-8 (not the same thing as unicode, as mentioned) but it's there.

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

#105

Post by nulltrace »

gmueckl wrote: post #102
ghighi7878 wrote: post #98

Earlier quoted context omitted.

Just because Bjarne thinks the feature is bad doesnt mean it is bad. He can be wrong. The point is, most peoppe disagree with him, and so a lot of peoppe do think it is good.

There have been several talks about contracts and the somewhat hidden complexities in them. C++ contracts are not like what you'd initally expect. Compiler switches can totally alter how contracts behave from getting omitted to reporting failures to aborting the program. There is also an optional global callback for when a contract check fails. Different TUs can be compiled with different settings for the contract be…

Coroutines went through the same cycle. Standardized in C++20, and I still hit compiler-specific differences in how symmetric transfer gets lowered.

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

#106

Post by kibwen »

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…

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

In the interest of pedantry, locating source files relative to the crate root is a language-level Rust feature, not something specific to Cargo. You can pass any single Rust source file directly to rustc (bypassing Cargo altogether) and it will treat it as a crate root and locate additional files as needed based on the normal lookup rules.

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

#107

Post by DenisM »

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…

>to a language which has already surpassed its complexity budget

I've been thinking that way for many years now, but clearly I've been wrong. Perhaps C++ is the one language to which the issue of excess complexity does not apply.

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

#108

Post by selfmodruntime »

DenisM wrote: post #107
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…

>to a language which has already surpassed its complexity budget I've been thinking that way for many years now, but clearly I've been wrong. Perhaps C++ is the one language to which the issue of excess complexity does not apply.

In essence, a standard committee thinks like bureaucrats. They have little to no incentive to get rid of cruft and only piling on new stuff is rewarded.

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

#109

Post by scrubs »

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…

Yep ... go/zig pkg management has the same benefit compared to c/c++.

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

#110

Post by stackghost »

hansvm wrote: post #96
stackghost wrote: post #86

Earlier quoted context omitted.

>the mandate ended, and Ada faded from the spotlight Exactly. People stopped using Ada as soon as they were no longer forced to use it. In other words on its own merits people don't choose it.

On their own merits, people choose SMS-based 2FA, "2FA" which lets you into an account without a password, perf-critical CLI tools written in Python, externalizing the cost of hacks to random people who aren't even your own customers, eating an extra 100 calories per day, and a whole host of other problematic behaviors. Maybe Ada's bad, but programmer preference isn't a strong enough argument. It's just as likely tha…

I made no judgement about whether Ada is subjectively "bad" or not. I used it for a single side project many years ago, and didn't like it.

But my anecdotal experience aside, it is plain to see that developers had the opportunity to continue with Ada and largely did not once they were no longer required to use it.

So, it is exceedingly unlikely that some conspiracy against C++, motivated by mustache-twirling Ada gurus, is afoot. And even if that were true, knocking C++ down several pegs will not make people go back to Ada.

C#, Rust, and Go all exist and are all immensely more popular than Ada. If there were to be a sudden exodus of C++ developers, these languages would likely be the main beneficiaries.

My original point, that C++ isn't what's standing in the way of Ada being popular, still stands.

Post reply on HN