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

151–160 of 437 posts

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

#151

Post by mcdeltat »

Guvante wrote: post #133
kajaktum wrote: post #121

Earlier quoted context omitted.

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.

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

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

#152

Post by [deleted] »

jjmarr wrote: post #40
VerifiedReports wrote: post #33

As long as programmers still have to deal with header files, all of this is lipstick on a pig.

You don't on new projects. CMake + ninja has support for modules on gcc, clang, and MSVC. This should be your default stack on any small-to-medium sized C++ project. Bazel, the default pick for very large codebases, also has support for C++20 modules.

[deleted]

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

#153

Post by WalterBright »

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

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

#154

Post by WalterBright »

selfmodruntime wrote: post #108
DenisM wrote: post #107

Earlier quoted context omitted.

>to a language which has already surpassed its complexity budget I've been thinking that way for many years now, but clearly I've been wrong. Perhaps C++ is the one language to which the issue of excess complexity does not apply.

In essence, a standard committee thinks like bureaucrats. They have little to no incentive to get rid of cruft and only piling on new stuff is rewarded.

In D, we are implementing editions so features that didn't prove effective can be removed.

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

#155

Post by WalterBright »

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;

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.

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

#156

Post by jibal »

Maxatar wrote: post #38
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…

Without a significant amount of needed context that quote just sounds like some awkward rambling. Also almost every feature added to C++ adds a great deal of complexity, everything from modules, concepts, ranges, coroutines... I mean it's been 6 years since these have been standardized and all the main compilers still have major issues in terms of bugs and quality of implementation issues. I can hardly think of any m…

It doesn't sound that way to me, but there's a lot of context at https://youtu.be/tzXu5KZGMJk?t=3160

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

#157

Post by Negitivefrags »

WalterBright wrote: post #155
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;

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.

That is a way better syntax. I wonder why C++ didn't adopt it.

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

#158

Post by creato »

m-schuetz wrote: post #10
forrestthewoods wrote: post #5

Earlier quoted context omitted.

No. Modules are a failed idea. Really really hard for me to see them becoming mainstream at this point.

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.

The idea is great in the same way the idea of a perpetual motion machine is great: I'd love to have a perpetual motion machine (or C++ modules), but it's just not realistic.

IMO, the modules standard should have aimed to only support headers with no inline code (including no templates). That would be a severe limitation, but at least maybe it might have solved the problem posed by protobuf soup (AFAIK the original motivation for modules) and had a chance of being a real thing.

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

#159

Post by jcalvinowens »

Negitivefrags wrote: post #157
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.

That is a way better syntax. I wonder why C++ didn't adopt it.

There's a whole section on that: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p27...

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

#160

Post by extrabajs »

addaon wrote: post #63
derriz wrote: post #26

Earlier quoted context omitted.

C++ is the last language I'd add to any list of languages used for correct-by-design - it's underspecified in terms of semantics with huge areas of UB and IB. Given its vast complexity - at every level from the pre-processor to template meta-programming and concepts, I simply can't imagine any formal denotational definition of the language ever being developed. And without a formal semantics for the language, you can…

As with Spark, proving properties over a subset of the language is sufficient. Code is written to be verified; we won’t be verifying interesting properties of large chunks of legacy code in my career span. The C (near-) subset of C++ is (modulo standard libraries) a starting point for this; just adding on templates for type system power (and not for other exotic uses) goes a long way.

I don’t think this is a good comparison. Ada (on which Spark is based) has every safety feature and guardrail under the sun, while C++ (or C) has nothing.
Post reply on HN