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

361–370 of 437 posts

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

#361

Post by menaerus »

aw1621107 wrote: post #354
menaerus wrote: post #348

Earlier quoted context omitted.

> Rust is quite capable of expression templates, as its iterator adapters prove. AFAIU iterator adapters are not quite what expression templates are because they rely on the compiler optimizations rather than the built-in feature of the language, which enable you to do this without relying on the compiler pipeline.

I had always thought expression templates at the very least needed the optimizer to inline/flatten the tree of function calls that are built up. For instance, for something like x + y * z I'd expect an expression template type like sum > where sum would effectively have: vector l; product& r; auto operator[](size_t i) { return l[i] + r[i]; } And then product would effectively have: vector l; vector r; auto operator[]…

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 and function folding though inlining which is pretty much basics in any c++ compiler and happens automatically without special care.

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

#362

Post by aw1621107 »

menaerus wrote: post #361
aw1621107 wrote: post #354

Earlier quoted context omitted.

I had always thought expression templates at the very least needed the optimizer to inline/flatten the tree of function calls that are built up. For instance, for something like x + y * z I'd expect an expression template type like sum > where sum would effectively have: vector l; product& r; auto operator[](size_t i) { return l[i] + r[i]; } And then product would effectively have: vector l; vector r; auto operator[]…

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

Take something like the above example for instance - w = x + y * z for vectors w/x/y/z. How do you get from that to effectively

    for (size_t i = 0; i
without involving the optimizer at all?

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

#363

Post by jcalvinowens »

Joker_vD wrote: post #245
tialaramex wrote: post #222

Earlier quoted context omitted.

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.

Consume is dead. Long live acquire!

But seriously, it is interesting how C++ is completely abandoning the concept. My handwavy understanding is that on some more specialized hardware acquire is substantially more expensive than consume.

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

#364

Post by WalterBright »

poppadom1982 wrote: post #337
WalterBright wrote: post #154

Earlier quoted context omitted.

In D, we are implementing editions so features that didn't prove effective can be removed.

Yeah dude but you've really marketed D poorly. I remember looking at D what must be 15 years back or so? And I loved the language and was blown away by its beauty and cool features. But having no FOSS compiler and the looming threat of someone claiming a patent (back then it was unclear that Mono/C# was "legal" and even Java hung in the balance) was too scary for me to touch it. Now I'm old and I believe D has missed…

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

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

#365

Post by jandrewrogers »

aw1621107 wrote: post #331
jandrewrogers wrote: post #327

Earlier quoted context omitted.

C++26 adds destructive moves. They are called relocatable types. There are edge cases where destructive moves are not safe and it is impossible for the compiler to know they aren't safe. C++ uses non-destructive moves when it can't prove the safety of destructive moves, even if destructive moves may in fact be safe. C++26 adds a type annotation that guarantees destructive moves are safe in cases where you can't prove…

> C++26 adds destructive moves. They are called relocatable types. I thought those were removed? For example, see Herb's 2025-11/Kona trip report [0]: > For trivial relocatability, we found a showstopper bug that the group decided could not be fixed in time for C++26, so the strong consensus was to remove this feature from C++26. [0]: https://herbsutter.com/2025/11/10/trip-report-november-2025-...

Good catch, very possible. I was surprised to see it listed as included when I searched. It may be stale information.

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

#366

Post by throwawaypath »

the__alchemist wrote: post #43
throwawaypath wrote: post #41

Earlier quoted context omitted.

Please don't use Hacker News as a religious or ideological battleground. It tramples curiosity. Please don't pick the most religiously/ideologically provocative thing in an article or post to complain about in the thread. Find something interesting to respond to instead.

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 a religious or ideological background here. Could you please clarify?

US leftist's obsession with race and gender is religious/ideological.

>I also believe it is your post that could be more accurately described as trampling curiosity; I believe there is a role reversal, in that I think your comment is a better description for trampling curiosity than the post your are responding.

This is what every religious/ideological zealot says when they're denied a platform to spew their nonsense.

Please review the guidelines linked above.

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

#367

Post by jandrewrogers »

affenape wrote: post #352
jandrewrogers wrote: post #327

Earlier quoted context omitted.

C++26 adds destructive moves. They are called relocatable types. There are edge cases where destructive moves are not safe and it is impossible for the compiler to know they aren't safe. C++ uses non-destructive moves when it can't prove the safety of destructive moves, even if destructive moves may in fact be safe. C++26 adds a type annotation that guarantees destructive moves are safe in cases where you can't prove…

From the proposal, I see a bunch of new keywords and rules - alright given the language's heritage. But what happens if I "relocate" a variable value - would a "shell" remain or how exactly C++ is supposed to handle this: auto value = create_value(); if (some_cond) { consume_value(std::move(value)); // not sure whether it's move here, but I guess my point is clear } use_value(value);

My assumption is that this would produce a compiler error. Depending on whether or not the branch is taken, you would essentially be accessing an uninitialized value. Compilers already catch this type of case.

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

#368

Post by WalterBright »

bluGill wrote: post #271
Negitivefrags wrote: post #157

Earlier quoted context omitted.

That is a way better syntax. I wonder why C++ didn't adopt it.

Because you can't adopt that syntax after the fact. there is 30 years of C++ in the real world, initializing everything by default unless you opt-in will break some performance critical code that should not initialize everything (until it is updated manually - it has to be manual because tools are not smart enough to know where something was intentionally not initialized 100% of the time) Thus the current erroneous.…

> Because you can't adopt that syntax after the fact.

The `= void` syntax can be because it is currently not valid.

D (unlike C++) always has a default initializer, but does not allow a default constructor. This is sometimes controversial, but it heads off all kinds of problems.

The default initializer for floating point values is NaN. (And for chars it is 0xFF.) The point of this is for the value to not "happen" to work.)

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

#369

Post by WalterBright »

mort96 wrote: post #216
WalterBright wrote: post #153

Earlier quoted context omitted.

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

How do you know nobody wanted it?

I listen to the users. There was never any mention of it.

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

#370

Post by WalterBright »

locknitpicker wrote: post #223
WalterBright wrote: post #153

Earlier quoted context omitted.

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

> Nobody wanted it. The fact that the C++ standard community has been working on Contracts for nearly a decade is something that by itself automatically refutes your claim. I understand you want to self-promote, but there is no need to do it at the expense of others. I mean, might it be that your implementation sucked?

35 years is a lot longer than a decade. C++ should have copied the '= void;' syntax, too!
Post reply on HN