Live data from Hacker News

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

herbsutter.com

91–100 of 437 posts

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

#91
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 particularly. And while we're at it, let us us a class' name as a namespace for static methods, so that Obj::f the static method is simply the method f in namespace Obj.

3. Get compiler makers to have an ABI break, so that we can do things like passing wrapped values in registers rather than going through memory. See: https://stackoverflow.com/q/58339165/1593077

4. Get rid of the current allocators in the standard library, which are type-specific (ridiculous) and return pointers rather than regions of memory. And speaking of memory regions (i.e. with address and size but no element type) - that should be standardized too.

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

#92

> Second, conforming compiler and standard library implementations are coming quickly. Throughout the development of C++26, at any given point both GCC and Clang had already implemented two-thirds of C++26 features. Today, GCC already has reflection and contracts merged in trunk, awaiting release. How far is Clang on reflection and contracts?

Clang’s C++2c implementation status page simply says “no” for both reflection and contracts. GCC’s says “yes”.

https://clang.llvm.org/cxx_status.html

https://gcc.gnu.org/projects/cxx-status.html

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

#93
post #17
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…

> Programming languages used for correct-by-design software (Ada, C++, Rust) ...

A shoutout to Eiffel, the first "modern" (circa 1985) language to incorporate Design by Contract. Well done Bertrand Meyer!

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

#94

Earlier quoted context omitted.

It's fundamentally different; Rust entirely rejects the notion of a stable ABI, and simply builds everything from source. C and C++ are usually stuck in that antiquated thinking that you should build a module, package it into some libraries, install/export the library binaries and associated assets, then import those in other projects. That makes everything slow, inefficient, and widely dangerous. There are of course…

>There are of course good ways of building C++, but those are the exception rather than the standard. What are the good ways?

"Do not do it" looks like the winning one nowadays.

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

#95
post #74

"Japanese soldier who kept fighting 29 years after World War 2"

I watched a talk from Bjarne Stroustrup at CppCon about safety and it was pretty second hand embarrassing watching him try to pretend C++ has always been safe and safety mattered all along to them before Rust came along.

Well, there has been a long campaign against manual memory management - well before Rust was a thing. And along with that, a push for less use of raw pointers, less index loops etc. - all measures which, when adopted, reduce memory safety hazards significantly. Following the Core Guideliness also helps, as does using span's. Compiler warnings has improved, as has static analysis, also in a long process preceding Rust.

Of course, this is not completely guaranteed safety - but safety has certainly mattered.

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

#96

Earlier quoted context omitted.

Ada used to be mandated in the US defense industry, but lots of developers and companies preferred C++ and other languages, and for a variety of reasons, the mandate ended, and Ada faded from the spotlight.

>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 that newer software is buggier and more unsafe or that this otherwise isn't an apples-to-apples comparison.

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

#97

Earlier quoted context omitted.

The idea is great, the execution is terrible. In JS, modules were instantly popular because they were easy to use, added a lot of benefit, and support in browsers and the ecoysystem was fairly good after a couple of years. In C++, support is still bad, 6 years after they were introduced.

Exactly. C++ is still waiting for its "uv" moment, so until then modules aren't even close to solved.

And uv required some ground work, where the PEP process streamlined how you define a python project, and then uv could be built on top.

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

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

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

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

Can you share what aspects of the design you (and Stroustroup) aren't happy with? Stroustroup has a tendency of being proven right, with 1-3 decade lag.

Well thats not always true. Initializer list is a glaring example. So are integer promotion some other things like

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

#100
post #81

Earlier quoted context omitted.

It's fundamentally different; Rust entirely rejects the notion of a stable ABI, and simply builds everything from source. C and C++ are usually stuck in that antiquated thinking that you should build a module, package it into some libraries, install/export the library binaries and associated assets, then import those in other projects. That makes everything slow, inefficient, and widely dangerous. There are of course…

"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 instructions being manipulated, generating tighter optimizations.
Post reply on HN