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

221–230 of 437 posts

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

#221

Post by locknitpicker »

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

I don't think this opinion is well informed. Contracts are a killer feature that allows implementing static code analysis that covers error handling and verifiable correct state. This comes for free in components you consume in your code.

https://herbsutter.com/2018/07/02/trip-report-summer-iso-c-s...

Asserting that no one wants their code to correctly handle errors is a bold claim.

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

#222

Post by tialaramex »

Joker_vD wrote: post #202
ozgrakkurt wrote: post #178

Earlier quoted context omitted.

I know roughly what indeterminate means in english but it is not obvious to me when I see something like this in code. So I would have to look it up and be very careful about it since I can break something easily in C++. This just makes things more difficult from the perspective of using/learning the language. Similar problem with "unsequenced" and "reproducible" attributes added in c. It sounded cool after I took th…

I wonder if you're fine with const, constexpr and volatile also being things. I mean, "const" really doesn't mean what one would naively think (that's what "constexpr" is actually for) and the semantics of "volatile" are also widely misunderstood.

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 change things, constexpr says this function is shiny and modern and has no other real meaning (hence "constexpr all the things" memes, you might as well) but consteval does mean that we're promising this must always be evaluated at compile time, so the evaluation is frozen by runtime, however only a function can have this label.

Volatile is a mess because what you actually want are the volatile intrinsics, indeed you might want more (or fewer) depending on the target. If your target can do single bit hardware writes it'd be nice to provide an intrinsic for that, rather than hoping you can write in code REG |= 0x40 and have that write a single bit... which on platforms which do not have this single bit write feature that's going to compile to an unsynchronized read-modify-write which may cause problems. However instead of having intrinsics C's volatile was hacked into the type system instead and C++ tries to keep that.

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

#223

Post by locknitpicker »

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

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

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

#224

Post by mgaunard »

uecker wrote: post #170
mgaunard wrote: post #119

Earlier quoted context omitted.

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.

C simply has less wording for it because less work has been put into it.

The same problems exist.

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

#225

Post by happyweasel »

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?

In the early 1990s, C++ had not yet been standardized by ISO, so your argument doesn’t apply to that period.

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

#226

Post by vintagedave »

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?

Late nineties is approaching thirty decades ago; if the C++ committee has now been working on this for nearly a decade, that's fifteen to twenty years of them not working on it. It's quite plausible that contracts simply weren't valued at the time.

Also, in my view the committee has been entertaining wider and wider language extensions. In 2016 there was a serious proposal for a graphics API based on (I think) Cairo. My own sense is that it's out of control and the language is just getting stuff added on because it can.

Contracts are great as a concept, and it's hard to separate the wild expanse of C++ from the truly useful subset of features.

There are several things proposed in the early days of C++ that arguably should be added.

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

#227

Post by [deleted] »

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?

[deleted]

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

#228

Post by mgaunard »

maccard wrote: post #204
mgaunard wrote: post #123

Earlier quoted context omitted.

I have several times built my own system to do just that when it wasn't even my main job. Doesn't take more than a couple of days. Bazel is certainly not the solution; it's arguably closer to being the problem. The worst build system I have ever seen was Bazel-based.

> I have several times built my own system to do just that when it wasn't even my main job. Doesn't take more than a couple of days. Really? I'd love a link to even something that works as a toy project > Bazel is certainly not the solution; it's arguably closer to being the problem. The worst build system I have ever seen was Bazel-based. I agree

It usually ends up somewhat non-generic, with project-specific decisions hardcoded rather than specified in a config file.

I usually make it so that it's fully integrated with wherever we store artifacts (for CAS), source (to download specific revisions as needed), remote running (which depending on the shop can be local, docker, ssh, kubernetes, ...), GDB, IDEs... All that stuff takes more work for a truly generic solution, and it's generally more valuable to have tight integration for the one workflow you actually use.

Since I also control the build image and toolchain (that I build from source) it also ends up specifically tied to that too.

In practice, I find that regardless of what generic tool you use like cmake or bazel, you end up layering your own build system and workflow scripts on top of those tools anyway. At some point I decided the complexity and overhead of building on top of bazel was more trouble than it was worth, while building it from scratch is actually quite easy and gives you all the control you could possibly need.

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

#229

Post by pjmlp »

wpollock wrote: post #93
addaon wrote: post #17

Earlier quoted context omitted.

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!

With people still paying to get the compiler, https://www.eiffel.com

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

#230

Post by Sharlin »

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…

Problem is contracts mean different things to different people, and that leads standard contracts support being a compromise that makes nobody happy. To some people contracts are something checked at runtime in debug mode and ignored in release mode. To others they’re something rigorous enough to be usable in formal verification. But the latter essentially requires a completely new C++ dialect for writing contract assertions that has no UB, no side effects, and so on. And that’s still not enough as long as C++ itself is completely underspecified.
Post reply on HN