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

281–290 of 437 posts

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

#281

Post by einpoklum »

pjmlp wrote: post #234
einpoklum wrote: post #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 pa…

The C++ WG is like any other open source project, even when it doesn't look like it. Someone has to bring a written spec to WG21 meetings and push it through. And like in every open source project that doesn't go the way we like, the work is only done by those that show up.

> The C++ WG is like any other open source project, even when it doesn't look like it.

In many ways, it isn't.

> Someone has to bring a written spec to WG21 meetings and push it through.

That is one way it is not like (most) other FOSS projects. In a typical FOSS project, there are bug reports and feature/change requests that people file. They don't have to write a full article merely for their idea to be given the time of day. Certainly not have to appear physically at meetings held elsewhere in the world. Of course, the question of the extent to which ideas and requests from the public are considered seriously and fairly is a spectrum - some FOSS projects give them more attention and consider them seriously, others do not. vis-a-vis WG21 the "public" is, to some extent: Compiler author teams, standard library author teams, national bodies, and large corporations using C++. This is perhaps not entirely avoidable, since there are millions of C++ users, but still.

Anyway, what I described isn't just some personal ideas of mine, it is for the most part ideas which have been put forward before the committee, either directly in submitted papers or indirectly via public discussion in fora the committee is aware of.

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

#282

Post by aw1621107 »

Dylan16807 wrote: post #275
amluto wrote: post #247

Earlier quoted context omitted.

On a quick read of the paper, I see two surprising things: 1. If there’s no initializer and various conditions are met, then “the bytes have erroneous values, where each value is determined by the implementation independently of the state of the program. What does “independently” mean? Are we talking about all zeros? Is the implementation not permitted to use whatever arbitrary value was in memory? Why not? 2. What’s…

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

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

#283

Post by [deleted] »

amluto wrote: post #247
jcalvinowens wrote: post #49

The "erroneous behavior" redefinition for reads of uninitialized variables is really interesting: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p27... It does have a runtime cost. There's an attribute to force undefined behavior on read again and avoid the cost: int x [[indeterminate]]; std::cin >> x;

On a quick read of the paper, I see two surprising things: 1. If there’s no initializer and various conditions are met, then “the bytes have erroneous values, where each value is determined by the implementation independently of the state of the program. What does “independently” mean? Are we talking about all zeros? Is the implementation not permitted to use whatever arbitrary value was in memory? Why not? 2. What’s…

[deleted]

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

#284

Post by aw1621107 »

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

> 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

...But the change to EB in this case does initialize everything by default?

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

#286

Post by pjmlp »

einpoklum wrote: post #281
pjmlp wrote: post #234

Earlier quoted context omitted.

The C++ WG is like any other open source project, even when it doesn't look like it. Someone has to bring a written spec to WG21 meetings and push it through. And like in every open source project that doesn't go the way we like, the work is only done by those that show up.

> The C++ WG is like any other open source project, even when it doesn't look like it. In many ways, it isn't. > Someone has to bring a written spec to WG21 meetings and push it through. That is one way it is not like (most) other FOSS projects. In a typical FOSS project, there are bug reports and feature/change requests that people file. They don't have to write a full article merely for their idea to be given the t…

They kind of do, otherwise those RFC, PIP, TIP, PEP, JSR,... die out.

A pull request isn't enough, even if online collaboration is simpler than with ISO related meetings.

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

#287

Post by duped »

FrostKiwi wrote: post #141
duped wrote: post #131

Earlier quoted context omitted.

I have yet to see modules in the wild. What I have seen extensively are header-only projects.

It's the fault of built systems. CMake still doesn't support `import std` officially and undocumented things are done in the ecosystem [1] But once it works and you setup the new stuff, having started a new CPP26 Project with modules now, it's kinda awesome. I'm certainly never going back. The big compilers are also retroactively adding `import std` to CPP20, so support is widening. [1] https://gitlab.kitware.com/cma…

weird to blame build systems for a problem caused by the language

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

#288

Post by duped »

bluGill wrote: post #274
duped wrote: post #131

Earlier quoted context omitted.

I have yet to see modules in the wild. What I have seen extensively are header-only projects.

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

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

#289

Post by germandiago »

vintagedave wrote: post #226
locknitpicker wrote: post #223

Earlier quoted context omitted.

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

I am not sure what the "truly useful features are" if you take into account that C++ goes from games to servers to embedded, audio, heterogeneous programming, some GUI frameworks, real-time systems (hard real-time) and some more.

I would say some of the features that are truly useful in some niches are les s imoortant in others and viceversa.

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

#290

Post by einpoklum »

tourist2d wrote: post #149
einpoklum wrote: post #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 pa…

1. This seems like it's be far too tricky and make C++ even more footgunny, especially with references, move constructors, etc etc. 2. Name lookup and overload resolution is already so complex though! This will likely never be added because it's so core c++ and would break so much. imo, it also blurs the line between what's your interface vs what I've defined. 3. This is every junior c++ engineers suggestion. Having…

Re (1.): Not-having-footguns is not a basic design principle of C++. But principles which it is supposed to adhere to include:

* Don't pay for what you don't use;

* Not leaving for another language between C++ and assembly (or to phrase it differently: "when you use an abstraction mechanism appropriately, you get at least as good performance as if you had hand-coded using lower-level constructs")

and the lack of `restrict` breaks both of these, significantly. Because compilers are forced to implement even simple functions with repeated re-reading of data - due to the possibility of aliasing - which the software developer knows is entirely unnecessary, and would have avoided had he been writing the same function in, say, C (and of course compiler IR or assembly)

Re (2): It's not really "core C++": It would not make any existing program non-well-formed, nor change its semantics, at all. But it's true that this would have an impact on how we design classes - and that's the exact intent. And it does far more than "blur the line between what's your interface vs what I've defined" - it deletes most of this line, ,and that is exactly the point. The line we should have is the line of acccess restriction: Does a method have access to the class' private data, or doesn't it. If it doesn't, then, there are simply functions which take an oject of the class; and it doesn't matter if the class author defined them or if someone else defined them.

Re (3.): I didn't say lack of backwards compatibility, just that going forwards, ABIs would allow some things which are currently prevented [1]. I am not an ABI expert in the least, but IIUC, use of new ABI can be marked, so that nothing gets mixed up.

I would also claim that ABI stability should cede to the design principles I mentioned above.

[1]: https://cor3ntin.github.io/posts/abi/

Post reply on HN