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

161–170 of 437 posts

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

#161

Post by raverbashing »

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…

Geez if Bjarne thinks it's

> bloated committee design and also incomplete

That's truly in that backdoor alley catching fire

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

#162

Post by porise »

usrnm wrote: post #56
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

And yet, none of them work with std::regex etc.

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

#163

Post by ozgrakkurt »

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…

I don’t understand this “next evolution” approach to language design.

It should be done at some point. People can always develop languages with more or less things but piling more things on is just not that useful.

It sounds cool in the minds of people that are designing these things but it is just not that useful. Rust is in the same situation of adding endless crap that is just not that useful.

Specifically about this feature, people can just use asserts. Piling things onto the type system of C++ is never going to be that useful since it is not designed to be a type system like Rust's type system. Any improvement gained is not worth piling on more things.

Feels like people that push stuff do it because "it is just what they do".

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

#164

Post by ChrisGreenHeur »

WalterBright wrote: post #153
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 implemented Contracts in the C++ language in the early 90's as an extension. Nobody wanted it. https://www.digitalmars.com/ctg/contract.html

it could be possible that llms can mak great use of them

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

#165

Post by jandrewrogers »

mcdeltat wrote: post #151
Guvante wrote: post #133

Earlier quoted context omitted.

Why should C++ stop improving? Other languages don't need C++ to die to beat it.

Half-serious reason: because with each C++ version, we seem to get less and less what we want and more and more inefficiency. In terms of language design and compiler implementation. Are we even at feature-completeness for C++20 on major compilers yet? (In an actually usable bug-free way, not an on-paper "completion".)

The compiler design is definitely becoming more complicated but the language design has become progressively more efficient and nicer to use. I’ve been using C++20 for a long time in production; it has been problem-free for years at this point. It is not strictly complete, e.g. modules still aren’t usable, but you don’t need to wait for that to use it.

Even C++23 is largely usable at this point, though there are still gaps for some features.

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

#166

Post by riffraff »

selfmodruntime wrote: post #108
DenisM wrote: post #107

Earlier quoted context omitted.

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

The scheme folks managed to shed complexity between R6RS and R7RS, I believe.

So perhaps I think the issue is not committees per se, but how the committees are put together and what are the driving values.

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

#167

Post by [deleted] »

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…

[deleted]

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

#168

Post by uecker »

hansvm wrote: post #100
uecker wrote: post #81

Earlier quoted context omitted.

"That makes everything slow, inefficient, and widely dangerous." There nothing faster and more efficient than building C programs. I also not sure what is dangerous in having libraries. C++ is quite different though.

Of course there is. Raw machine code is the gold standard, and everything else is an attempt to achieve _something_ at the cost of performance, C included, and that's even when considering whole-program optimization and ignoring the overhead introduced by libraries. Other languages with better semantics frequently outperform C (slightly) because the compiler is able to assume more things about the data and instructio…

I was talking about building code not run-time. But regarding run-time, no other language does outperform C in practice, although your argument about "better semantics" has some grain of truth in it, it does not apply to any existing language I know of - at least not to Rust which is in practice for the most part still slower than C.

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

#169

Post by ozgrakkurt »

jcalvinowens wrote: post #49

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;

I envy the person that will walk into a c++ codebase and see "[[indeterminate]]" on some place. And then they will need to absolutely waste their time searching and reading what "[[indeterminate]]" means. Or over time they will just learn to ignore this crap and mentally filter it out when looking at code.

Just like when I was learning rust and trying to read some http code but it was impossible because each function had 5 generics and 2 traits.

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

#170

Post by uecker »

mgaunard wrote: post #119
uecker wrote: post #81

Earlier quoted context omitted.

"That makes everything slow, inefficient, and widely dangerous." There nothing faster and more efficient than building C programs. I also not sure what is dangerous in having libraries. C++ is quite different though.

ODR violations are very easy to trigger unless you build the whole thing from source, and are ill-formed, no diagnostic required (worse than UB).

Neither "ODR violations" nor IFNDR exist in C. Incompatibility across translation units can cause undefined behavior in C, but this can easily be avoided.
Post reply on HN