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

381–390 of 437 posts

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

#381

Post by amluto »

aw1621107 wrote: post #280
amluto wrote: post #247

Earlier quoted context omitted.

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…

> What does “independently” mean? It means what it says on the tin. Whatever value ends up being used must not depend on the state of the program. > Are we talking about all zeros? All zeros is an option, but the intent is to allow the implementation to pick other values as it sees fit: > Note that we do not want to mandate that the specific value actually be zero (like P2723R1 does), since we consider it valuable to…

> Doing so would defeat the purpose of the change, which is to turn nasal-demons-on-mistake into something with less dire consequences

What nasal demons?

UB is permitted to format your disk, execute arbitrary code, etc. But there’s lots of room between deterministic values and UB. For example, taking a value that does depend on the previous state of the program and calling it the “erroneous” value would give a non-UB, won’t format your hard disk solution. And it even makes quite a lot of performance sense: the value that was already in the register or at that address in memory is available for free! The difference from C++23 would be that using that value would merely be erroneous and not UB.

And I think the word “indeterminate” should have been reserved for that sort of behavior.

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

#382

Post by the__alchemist »

throwawaypath wrote: post #366
the__alchemist wrote: post #43

Earlier quoted context omitted.

This is interesting! People ignoring this, I think, is also interesting on its own. I respect if other people disagree, but that's my 2c. I think our overton windows may not agree here, but I think this is part of the value of discussions with other humans. Are you a moderator? The directive tone of this post is as if from an authority figure, but, but I do not believe you are one. I do not believe there is anything…

>This is interesting! No it's not. After a decade of the US-centric coastal leftist obsession with race and gender it is not interesting. It's about as interesting as Christians commenting on abortion. >Are you a moderator? The directive tone of this post is as if from an authority figure, but, but I do not believe you are one. https://news.ycombinator.com/newsguidelines.html >I do not believe there is anything about…

I do not think you are someone who I enjoy any form of communication with. I think you are not very nice.

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

#383

Post by germandiago »

ux266478 wrote: post #358
germandiago wrote: post #295

Earlier quoted context omitted.

But compile-time processing is certainly useful in a performance-oriented language. And not only for performance but also for thread safety (eliminates initialization races, for example, for non-trivial objects). Rust is just less powerful. For example you cannot design something that comes evwn close to expression templates libraries.

> And not only for performance but also for thread safety This is already built-in to the language as a facet of the affine type system. I'm curious as to how familiar you actually are with Rust? > Rust is just less powerful. On the contrary. Zig and C++ have nothing even remotely close to proc macros. And both languages have to defer things like thread safety into haphazard metaprogramming instead of baking them int…

Writing general generic code without repetition for Rust without specialization is ome thing where it fails. It does not have variadics or so powerful compile metaprogramming. It does not come even remotely close.

Proc macros is basically plugins. I do not think thos is even part of the "language" as such. It is just plugging new stuff into the compiler.

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

#384

Post by quuxplusone »

sidkshatriya wrote: post #269
ChrisGreenHeur wrote: post #164

Earlier quoted context omitted.

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

> it could be possible that llms can mak great use of them This is actually a good point. Yes, LLMs have saturated the conversation everywhere but contracts help clarify the pre-post conditions of methods well. I don't know how good the implementation in C++ will be but LLMs should be able to really exploit them well.

The problem with that is that C++26 Contracts are just glorified asserts. They trigger at runtime, not compile time. So if your LLM-generated code would have worked 99% of the time and then crashed in the field... well, now it will work 99% of the time and (if you're lucky) call the contract-violation handler in the field.

Arguably that's better (more predictable misbehavior) than the status quo. But it's not remotely going to fix the problem with LLM-generated code, which is that you can't trust it to behave correctly in the corner cases. Contracts can't make the code magically behave better; all they can do is make it misbehave better.

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

#385

Post by inetknght »

steveklabnik wrote: post #320
inetknght wrote: post #306

Earlier quoted context omitted.

I often see arguments like yours. I reject them wholeheartedly. Your argument is pro-poor-design. I tell you: design your software better. Design your software so that you can't have undefined behavior. It's harder, yes. LLMs suck at it, yes. But building well-designed software is a significant part of being a better engineer.

It is easier to design the software so that you don't have confusing behavior when you're not required to include behaviors you don't want. Most things do not need to be nullable. Requiring all things to have a zero value, even when they do not have one, makes it harder to be correct by construction, not easier.

> It is easier to design the software so that you don't have confusing behavior when you're not required to include behaviors you don't want.

It can be easier, but not always. But it is almost always a better design.

Redesigning software so that whole classes of problems simply can't exist is absolutely better than software that needs to handle all kinds of problems. Many of those problems might not even ever happen in real circumstances!

> Requiring all things to have a zero value, even when they do not have one, makes it harder to be correct by construction, not easier.

Don't require a "zero value". Require a "correctly-constructed" value. Sometimes zero is correctly constructed, sometimes not.

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

#386

Post by aw1621107 »

amluto wrote: post #381
aw1621107 wrote: post #280

Earlier quoted context omitted.

> What does “independently” mean? It means what it says on the tin. Whatever value ends up being used must not depend on the state of the program. > Are we talking about all zeros? All zeros is an option, but the intent is to allow the implementation to pick other values as it sees fit: > Note that we do not want to mandate that the specific value actually be zero (like P2723R1 does), since we consider it valuable to…

> Doing so would defeat the purpose of the change, which is to turn nasal-demons-on-mistake into something with less dire consequences What nasal demons? UB is permitted to format your disk, execute arbitrary code, etc. But there’s lots of room between deterministic values and UB. For example, taking a value that does depend on the previous state of the program and calling it the “erroneous” value would give a non-UB…

> What nasal demons?

Those that result from the pre-C++26 behavior where use of an indeterminate value is UB.

> But there’s lots of room between deterministic values and UB.

That's a fair point. I do think I made a mistake in how I represented the authors' decision, as it seems the authors intentionally wanted the predictability of fixed values (italics added):

> Reading an uninitialized value is never intended and a definitive sign that the code is not written correctly and needs to be fixed. At the same time, we do give this code well-defined behaviour, and if the situation has not been diagnosed, we want the program to be stable and predictable. This is what we call erroneous behaviour.

> And I think the word “indeterminate” should have been reserved for that sort of behavior.

Perhaps, but that'd be a departure from how the word has been/is used in the standard so there would probably be some resistance against redefining it.

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

#387

Post by celrod »

quuxplusone wrote: post #384
sidkshatriya wrote: post #269

Earlier quoted context omitted.

> it could be possible that llms can mak great use of them This is actually a good point. Yes, LLMs have saturated the conversation everywhere but contracts help clarify the pre-post conditions of methods well. I don't know how good the implementation in C++ will be but LLMs should be able to really exploit them well.

The problem with that is that C++26 Contracts are just glorified asserts. They trigger at runtime, not compile time. So if your LLM-generated code would have worked 99% of the time and then crashed in the field... well, now it will work 99% of the time and (if you're lucky) call the contract-violation handler in the field. Arguably that's better (more predictable misbehavior) than the status quo. But it's not remotel…

In my experience, llms don't reason well about expected states, contracts, invariants, etc. Partly because that don't have long term memory and are often forced to reason about code in isolation. Maybe this means all invariants should go into AGENTS.md/CLAUDE.md files, or into doc strings so a new human reader will quickly understand assumptions.

Regardless, I think a habit of putting contracts to make pre- and post-conditions clear could help an AI reason about code.

Maybe instead of suggesting a patch to cover up a symptom, an AI may reason that a post-condition somewhere was violated, and will dig towards the root cause.

This applies just as well to asserts, too. Contracts/asserts actually need to be added to tell a reader something.

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

#388

Post by VerifiedReports »

72deluxe wrote: post #206
VerifiedReports wrote: post #33

As long as programmers still have to deal with header files, all of this is lipstick on a pig.

I don't understand this at all. There are modules. But headers are perfectly fine to deal with and have been for decades and decades! Next you'll be arguing that contents pages in all books should be removed.

What an absurd attitude. The gymnastics to avoid circular inclusions alone are something nobody should be giving a thought to in the 2000s.

"But headers are perfectly fine to deal with and have been for decades and decades!"

I would have thought this was a joke... but your follow-up indicates otherwise.

So what are you going to float next? "So what if people broke their arms hand-cranking their cars to start them! People did it for years, so we shouldn't move to electric starters! Or automatic chokes!"

"And these electric ice boxes are for the birds! Speaking of which: People flying through the air in machines? POPPYCOCK!"

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

#389

Post by poppadom1982 »

WalterBright wrote: post #376
WalterBright wrote: post #364

Earlier quoted context omitted.

D is 100% open source. The gnu D compiler and the LLVM D compiler were always 100% open source.

I don't recall anyone making a patent claim.

Open source and free software isn't the same thing. Nobody made a claim on Java either, until someone did. I just distinctly remember explicitly not exploring D for that reason. Also this way way before LLVM and I also don't think GNU had a D compiler back then. There was only the (and I really believe it was closed source) Digital Mars compiler.

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

#390

Post by menaerus »

aw1621107 wrote: post #362
menaerus wrote: post #361

Earlier quoted context omitted.

Expression templates do not rely on optimizer since you're not dealing with the computations directly but rather expressions (nodes) through which you are deferring the computation part until the very last moment (when you have a fully built an expression of expressions, basically almost an AST). This guarantees that you get zero cost when you really need it. What you're describing is something keen of copy elision a…

> since you're not dealing with the computations directly but rather expressions (nodes) through which you are deferring the computation part until the very last moment (when you have a fully built an expression of expressions, basically almost an AST). Right, I understand that. What is not exactly clear to me is how you get from the tree of deferred expressions to the "flat" optimized expression without involving th…

The example is false because that's not how you would write an expression template for given computation so the question being how is it that the optimizer is not involved is also not quite set in the correct context so I can't give you an answer for that. Of course that the optimizer is generally going to be involved, as it is for all the code and not the expression templates, but expression templates do not require the optimizer in the way you're trying to suggest. Expression templates do not rely on O1, O2 or O3 levels being set - they work the same way in O0 too and that may be the hint you were looking for.
Post reply on HN