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

291–300 of 437 posts

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

#291

Post by randusername »

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…

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

This is a common sentiment about C++, but I find it very interesting that everyone seems to have a different feature in mind when they say it.

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

#292

Post by Dylan16807 »

aw1621107 wrote: post #282
Dylan16807 wrote: post #275

Earlier quoted context omitted.

> What does “independently” mean? It can pick whatever value it wants and doesn't have to care what the program is doing. Also the value has to stay the same until it's 'replaced'. > Are we talking about all zeros? It might be, but probably won't be. What makes you bring up all zeroes? > Is the implementation not permitted to use whatever arbitrary value was in memory? Why not? (Edit: probably wrong, also affects oth…

> It can. What suggests it wouldn't be able to? "Whatever value was in memory" would be depending on the (former?) state of the program, wouldn't it?

If that's what they're going for, it's way too much weight to hang on a single vague word like that. Trying to define "state of the program" in a detailed way sounds nightmarish. Let's say I'm the implementation. If I go get fresh (but not zeroed) memory from the OS to put my stack on, the garbage in there isn't state of the program, right? If I then run a function and the function exits, is the garbage now state of the program, or is it outside the state of the program? If I want a fixed init value per address, is that allowed as a hardening feature or disallowed as being based on allocation patterns? Does the as-if rule apply, so I'm fine if the program can't know for sure where I got my arbitrary byte values from?

And would that mean there's still no way to say "Don't waste time initializing it, but don't do any UB shenanigans either. (Basically, pretend it was initialized by a random number generator.)"

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

#293

Post by kwsp »

tialaramex wrote: post #273
WalterBright wrote: post #155

Earlier quoted context omitted.

D initializes all variables. If you don't provide an initializer, the compiler inserts the default initializer for it. But if you really, really want to leave it uninitialized, write: int x = void; where you're not writing that by accident.

> 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 don’t care that much about everything having a default (although it’s nice), but if a language insists on a default value for every type for safety, can’t you just use std::optional?

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

#294

Post by dataflow »

tbaeder wrote: post #181
dataflow wrote: post #140

Earlier quoted context omitted.

That much I'm aware, but that's just about feature availability. I was wondering how far the implementations have progressed internally, despite the features being unavailable.

Clang basically doesn't implement anything regarding reflection right now. There is some support for parsing ( https://github.com/llvm/llvm-project/blob/main/clang/test/Pa... ) but that's it. There are some open PRs for other parts though.

Thanks, yeah, I was worried that might be the case. Given how complicated these features sound, it makes me wonder if they're gonna finish before the decade is over...

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

#295

Post by germandiago »

sidkshatriya wrote: post #270
jandrewrogers wrote: post #171

Earlier quoted context omitted.

Many of the recent C++ standards have been focused on expanding and cleaning up its powerful compile-time and metaprogramming capabilities, which it initially inherited by accident decades ago. It is difficult to overstate just how important these features are for high-performance and high-reliability systems software. These features greatly expand the kinds of safety guarantees that are possible to automate and the…

One of the biggest knocks against Rust as a systems programming language is that it has weak compile-time and metaprogramming capabilities compared to Zig and C++ In the space of language design, everything "more powerful" is not necessary good. Sometimes less power is better because it leads to more optimisable code, less implementation complexity, less abstraction, better LSP support. TL;DR More flexibility and com…

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.

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

#296

Post by seertaak »

tialaramex wrote: post #117
seertaak wrote: post #73

Earlier quoted context omitted.

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.

Certainly we can say that Bjarne will insist he was right decades later. We can't necessarily guess - at the time - what it is he will have "always" believed decades later though.

You made me laugh!...Bjarne indeed can't be accused of being a modest man. And by some accounts, he's quite a political animal.

But in fairness, when was D&E first published? Argued for auto there, long before their acceptance. Argued for implicit template instantiation - thank god the "everything-must-be-explicit" curmudgeons were vanquished there, too.

He's got a pretty good batting average - certainly better than Herb Sutter.

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

#297

Post by bluGill »

duped wrote: post #288
bluGill wrote: post #274

Earlier quoted context omitted.

Modules need a lot of tooling. The tool vendors have been working hard on this for years. They have only just now said this is ready for early adopters. Most people are waiting for the early adopters to write the books on what best practices are - this needs a few more years of experience.

if something so simple needs years of experience it's poorly designed

Modules are not simple. They sound simple only to people who have never digged into them.

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

#298

Post by germandiago »

kajaktum wrote: post #121
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…

C++ needs to give itself up and make way for other, newer, modern, language that have far, far fewer baggage. It should be working with other language to provide tools for interop and migration. C++ will never, ever be modern and comprehensible because of 1 and 1 reason alone: backward compatibility. It does not matter what version of C++ you are using, you are still using C with classes.

A bureau from the top call is not the way to do it.

Just beat it. Ah, not so easy huh? Libraries, ecosystem, real use, continuous improvements.

Even if it does not look so "clean".

Just beat it, I will move to the next language. I am still waiting.

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

#299

Post by seertaak »

ghighi7878 wrote: post #99
seertaak wrote: post #73

Earlier quoted context omitted.

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

Integer promotion? - Stroustroup pleads C source compat else stillborn.

Initializes lists suck mainly because of C source compat constraints, too. In fact, most things that suck in C++ came from B via C.

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

#300

Post by germandiago »

mcdeltat wrote: post #151
Guvante wrote: post #133

Earlier quoted context omitted.

Why should C++ stop improving? Other languages don't need C++ to die to beat it.

Half-serious reason: because with each C++ version, we seem to get less and less what we want and more and more inefficiency. In terms of language design and compiler implementation. Are we even at feature-completeness for C++20 on major compilers yet? (In an actually usable bug-free way, not an on-paper "completion".)

Relfection was a desperate need. Useful and difficult to design feature.

There are also things like template for or inplace_vector. I think it has useful things. Just not all things are useful to everyone.

Post reply on HN