Live data from Hacker News

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

herbsutter.com

311–320 of 437 posts

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

#311
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…

Is there any good documentation about contracts? https://en.cppreference.com/w/cpp/language/contracts.html is incredibly confusing - its first displayed example seems to be an edge case where the assertion itself causes a mutation?

https://en.cppreference.com/w/cpp/language/function.html#Fun... is vaguely better, but still quite dense.

IMO the syntax makes things hard for a newcomer to the syntax to understand, which I see as core to any programming language's goals of community.

    double square_root(double num) asserts_pre(num >= 0)
would have been far more self-evident than just

    double square_root(double num) pre(num >= 0)
But I suppose brevity won out.

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

#312
post #129

Earlier quoted context omitted.

That is what I'm doing so I can get distributed builds working. It sucks and has taken me days of work.

It's pretty simple and works reliably as specified. I can only infer that your lack of familiarity was what made it take so long. Rebuilding GCC with specs does take forever, and building GCC is in general quite painful, but you could also use patchelf to modify the binary after the fact (which is what a lot of build systems do).

> I can only infer that your lack of familiarity was what made it take so long

Pretty much.

Trying to convert an existing build that doesn't explicitly declare object dependencies is painful. Rust does it properly by default.

For example, I'm discovering our clang toolchain has a transitive dependency on a gcc toolchain.

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

#313

C++ is so tantalizingly close to being an amazing embedded c++ language if they could JUST support first-class polymorphism. Embedded is such a perfect fit for interface-based programming, but because it cant determine call resolution outside of a single source file, EVERYTHING gets vtable'd, which ruins downstream optimizations. There's some ugly workarounds.... CRTP, c-style (common header + different source files.…

use templates.

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

#314

If you ask me (and why wouldn't you? :-)...) I really wish the C++ WG would do several things: 1. Standardize a `restrict` keyword and semantics for it (tricky for struct/class fields, but should be done). 2. Uniform Function Call Syntax! That is, make the syntax `obj.f(arg)` mean simply `f(obj, arg)` . That would make my life much easier, both as a user of classes and as their author. In my library authoring work pa…

re 3, clang has [[trivial_abi]] (and I believe GCC is also implementing it. But it won't be applied to standard types by default, because of course is ABI breaking. You'll have to derive your own.

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

#315
post #143

Earlier quoted context omitted.

That sounds like the worst kind of misfeature. It sounds like it should solve your problem. At first it seems to work. Then you keep on finding the footguns after it is too late to change the design.

Contracts are designed as a minimum thing that can work. The different groups who want different - conflicting - things out of contracts now have a common place and syntax examples to start adding what they want without coming up with something that either breaks someone else, or worse each group doing things in a non-uniform way thus causing foot guns. Contracts as they are today won't solve every problem. However t…

I think that a "minimal viable baseline" type implementation should not break the ODR.

In Rust these types of proposals are common, in C++ less so. The incredibly tedious release process encourages everyone to put in just as much complexity as they can safely get away with.

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

#316
Dammit, it's been 28 years and they still haven't implemented my favorite C++ extension proposal, and its birthday is coming in a couple days -- it would be so much better now with all the emojis in unicode:

Generalizing Overloading for C++2000

https://www.stroustrup.com/whitespace98.pdf

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

#317
post #311
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…

Is there any good documentation about contracts? https://en.cppreference.com/w/cpp/language/contracts.html is incredibly confusing - its first displayed example seems to be an edge case where the assertion itself causes a mutation? https://en.cppreference.com/w/cpp/language/function.html#Fun... is vaguely better, but still quite dense. IMO the syntax makes things hard for a newcomer to the syntax to understand, which…

I believe that https://isocpp.org/files/papers/P2900R14.pdf is the paper, which doesn't mean it's good documentation, as it's meant for modifying the standard. However, in its early sections, it does link to other papers which have more information, and the "proposed wording" section should be where the standardize lives, with the rest of it being context.

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

#318

Quite unrelated to the main topic, but shouldn't it be Croydon, London? I have never heard anyone called it London Croydon before. Generally addresses/places go from most specific to least and given Croydon is an area of London it should go first.

Yes, I noticed that too -- why "London Croydon" rather than "Croydon, London" ? Date in Europe: 30/03/2026 Date in China: 2026/03/30 Then you have Little Endian and you have Big Endian. TL;DR: Some humans like to talk about the specific and then the general and others vice versa. But here is really why I think the author referred to it as "London, Croydon" "London, Croydon" communicates "Hey we had this C++ standards…

Generously - specifying Croydon does help travellers figure out where they need to be more specifically than just London. I'd like to hope if they met in New York City it'd say e.g. "New York - Riverdale" or something rather than leaving you to guess where in the city exactly.

Most things "in" London aren't in the centre unless they're tourist destinations or they're extremely old. The most surprising thing I ran into right in the centre was the International Maritime Organisation's headquarters, which is right on the Thames because historically that makes sense in a way that arguably it already didn't when that was built, and certainly not today.

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

#319

C++ is so tantalizingly close to being an amazing embedded c++ language if they could JUST support first-class polymorphism. Embedded is such a perfect fit for interface-based programming, but because it cant determine call resolution outside of a single source file, EVERYTHING gets vtable'd, which ruins downstream optimizations. There's some ugly workarounds.... CRTP, c-style (common header + different source files.…

> I've seen some examples of C++ contracts replacing CRTP, but it used templates, which again, not a fan of.

I think you meant concepts.

C++ Concepts are the right answer in my opinion, if you want compile time polymorphism against an interface.

I don't think, there is a way around templates, they are C++'s way of compile-time polymorphism. Other languages, which allow for compile-time polymorphism, have similar mechanisms with similar constraints. I get where you come from, when you say that you're not a fan of templates, though. At least concepts help with clearer error messages for templates.

One advantage, that concepts have over CRTP is, that only consumers of your interface, not implementers, need to know about your concept.

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

#320

Earlier quoted context omitted.

> If you don't provide an initializer, the compiler inserts the default initializer for it. This requires that there is a default. Several modern languages (such as Go) insist on this, it means now your types don't even model reality in this very fundamental way. Who is a person's default spouse? Even where you can imagine a default it's sometimes undesirable to have one, for example we already live in a society wher…

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.
Post reply on HN