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

411–420 of 437 posts

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

#411

Post by forrestthewoods »

germandiago wrote: post #303
forrestthewoods wrote: post #82

Earlier quoted context omitted.

I emphatically agree. C++ needs a standard build system that doesn’t suck ass. Most people would agree it needs a package manager although I think that is actually debatable. Neither of those things require modules as currently defined.

That is not even half realistic. Are you going to port all that code out there (autotools, cmake, scons,meson, bazel, waf...) to a "true" build system? Only the idea is crazy. What Conan does is much more sensible: give s layer independent of the build system (and a way to consume packages and if you want some predefined "profiles" such as debug, etc), leave it half-open for extensions and let existing tools talk wit…

Are the perfectly working build systems in the room with us now? Cmake and Conan ain’t it.

> That is not even half realistic.

uv is an existence proof that when you make something that doesn’t suck ass the entire industry will very very rapidly converge.

Claude makes converting any particular configuration from one system to another very very very tractable.

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

#412

Post by jcalvinowens »

Joker_vD wrote: post #379
jcalvinowens wrote: post #363

Earlier quoted context omitted.

Consume is dead. Long live acquire! But seriously, it is interesting how C++ is completely abandoning the concept. My handwavy understanding is that on some more specialized hardware acquire is substantially more expensive than consume.

If by "more specialized hardware" you mean "everything that is not x86". Its main intended use is (was?) for chained loads and rcu_dereference(), where hardware does not require an explicit memory fence between loads like ldr x8, [x8] # load a pointer from memory ldr x1, 16[x8] # load a field through that pointer or turning the second load into "ldar" — there is quite a visible data dependency between two registers.…

I'm not saying it doesn't matter. It just clearly doesn't matter enough on modern common non-tso CPUs enough to motivate anybody to add the compiler support. The history of the whole thing is very interesting.

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

#413

Post by lmm »

smallstepforman wrote: post #218
zarzavat wrote: post #142

Earlier quoted context omitted.

Also, having one standard packaging format and registry doesn't preclude having alternatives for special use cases. There should be a happy path for the majority of C++ use cases so that I can make a package, publish it and consume other people's packages. Anyone who wants to leave that happy path can do so freely at their own risk. The important thing is to get one system blessed as The C++ Package Format by the sta…

In the Linux world and even Haiku, there is a standard package dependacy format, so dependencies aren’t really a problem. Even OSX has Homebrew. Windows is the odd man out.

On the contrary, most Linux distributions use platform-specific global-only packaging formats for C++ libraries, and if anything I think that's holding back the development of a real, C++-native packaging/dependency manager.

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

#414

Post by Defletter »

WalterBright wrote: post #408
Defletter wrote: post #398

Earlier quoted context omitted.

It should copy Zig's '= undefined;' instead of D's '= void;' The latter is very confusing: why have a keyword that means nothing, but also anything? This is a pretty common flaw within D, see also: static.

Nobody in D was confused by `= void;`. People understood it immediately. > why have a keyword that means nothing, but also anything? googling void: "A void is a space containing nothing, a feeling of utter emptiness, or a legal nullity, representing a state of absolute vacancy or lack." Sounds perfect!

"People" doesn't include me then. I had no idea that D had this feature for quite some time, despite using it fairly often in Zig, because when considering what the equivalent would be to search for, my brain somehow didn't make the leap to the keyword that represents literally nothing. Or as your Google search result says, "representing a state of absolute vacancy or lack." A less inappropriate use of "= void;" would be to zero-out something. I honestly find D's continual misuse of keywords like this to be really off putting and a contributing factor as to why I've stopped using it.

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

#415

Post by Defletter »

WalterBright wrote: post #407
Defletter wrote: post #400

Earlier quoted context omitted.

But then why did you add your contract system to D? You implemented your contract system in the "early 90's", and D was released in 2001, so that's near a decade of "nobody wanted it". So then why add them as a core language feature of a new programming language if no one wanted it? Why is it still a core language feature? And why object to C++ finally adding contracts. I just don't get what you're even arguing here.

It's a great question! I simply had faith that it was a good idea. The reason I started D in the first place is the C++ community was uninterested in any of my ideas for improvement. Ironically, C++ would up adopting a lot of them one by one! Such as contracts! Contracts did find an enthusiastic constituency in the D community.

Contracts are a good idea, but I find the implementation of them to be clunky. I'd much rather contracts be part of the type system than as function signatures. Using the example in your earlier link, instead of defining day's 1..31 range within the Date-struct invariant, you'd instead declare a "day" type that's an int whose value cannot exceed 31 or be less than 1. This would be checked and enforced anytime a variable of the type is [re]assigned, set as a field, or passed-in as a parameter.

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

#416

Post by Joker_vD »

jcalvinowens wrote: post #412
Joker_vD wrote: post #379

Earlier quoted context omitted.

If by "more specialized hardware" you mean "everything that is not x86". Its main intended use is (was?) for chained loads and rcu_dereference(), where hardware does not require an explicit memory fence between loads like ldr x8, [x8] # load a pointer from memory ldr x1, 16[x8] # load a field through that pointer or turning the second load into "ldar" — there is quite a visible data dependency between two registers.…

I'm not saying it doesn't matter. It just clearly doesn't matter enough on modern common non-tso CPUs enough to motivate anybody to add the compiler support. The history of the whole thing is very interesting.

As I understand it, it's the other way around: for x86 (which is TSO) the fence doesn't really matter because the "normal" load is already slowed down, but for ARM it does matter quite a bit, see e.g. [0] (admittedly old blog post) slightly lower on the page. But perhaps we did get to the point where even ARM CPUs and surrounding memory is already performant enough so that spurious fences aren't as noticeable.

[0] https://preshing.com/20140709/the-purpose-of-memory_order_co...

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

#417

Post by gpderetta »

aw1621107 wrote: post #405
menaerus wrote: post #403

Earlier quoted context omitted.

Look, I have just completed work on some high performance serialization library which avoids computing heavy expressions and temporary allocations all by using expression templates and no, optimization levels are not needed. The code works as advertised at O0 - that's the whole deal around it. If you have a genuine question you should ask one but please do not disguise so that it only goes to prove your point. I am n…

> If you have a genuine question you should ask one but please do not disguise so that it only goes to prove your point. I think my question is pretty simple: "How does an optimizer-independent expression template implementation work?" Evidently the resources I've found so far describe "optimizer-dependent expression templates", and apparently none of the "expression template" implementations I've had reason to look…

Expression templates do AST manipulation of expressions at compile time. Let's say you have a complex matrix expression that naively maps to multiple BLAS operations but can be reduced to a single BLAS call. With expression templates you can translate one to the other, this is a static manipulation that does not depend on compiler level. What does depend on the compiler is whether the incidental trivial function calls to operators gets optimized away or not. But, especially with large matrices, the BLAS call will dominate anyway, so the optimization level shouldn't matter.

Of course in many cases the optimization level does matter: if you are optimizing small vector operators to simd inlining will still be important.

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

#418

Post by skelpmargyar »

cemdervis wrote: post #213
armchairhacker wrote: post #212

Earlier quoted context omitted.

I wonder if C++ already has so much complexity, that it would actually be a good idea to ignore feature creep, and implement any feature with even the most remote use-case. It sounds (and probably is) insane. But if a feature breaks backwards compatibility, or can't be implemented in a way that non-negligibly affects compiler/IDE performance for codebases that ignore it, what's the issue? Specifically, what significa…

GCC and MSVC are pretty close. fyi, the tables on cppreference are rather outdated at this point. I made a more up-to-date, community-maintained site: https://cppstat.dev/?conformance=cpp20

On the main page, it took me a minute after laughing at "std::byte arithmetic" to realize it was April 1st. All of those C++29 "features" are on point, very funny. Though surely there's somewhere SFINAE can be mentioned...

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

#419

Post by uecker »

mgaunard wrote: post #401
uecker wrote: post #353

Earlier quoted context omitted.

The ODR problem is much more benign in C. Undefined behavior at translation time (~ IFNDR) still exists in C but for C2y we have removed most of it already.

You can't fundamentally solve the issue of what happens if you call a function in another TU that takes a T but the caller and the callee have a different definition of T. Whether you call that IFNDR or UB doesn't make much of a difference. C++ mitigates that issue with its mangling (which checks the type name is the same), Rust goes the extra mile and puts a hash of the whole definition of the arguments in the symbo…

C++ ODR requires different definition to consist of the same tokens, and if not the the program is IFNDR. Name mangling catches some stuff, but this becomes less relevant today with more things being generated via templates from headers.

In C, it is UB when the types are not compatible, which is more robust. In practice it also easy to avoid with the same solution as in C++, i.e. there is a single header which declares the object. But even if not, tooling can check consistency across TU it is just not required by the ISO standard (which Rust does not have, so the comparison makes no sense). In practice, with GCC a LTO build detects inconsistencies.

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

#420

Post by saagarjha »

tialaramex wrote: post #256
saagarjha wrote: post #211

Earlier quoted context omitted.

If Rust makes no progress towards choosing an ABI and decides that freezing things is bad, then Rust is de facto rejecting the notion of a stable ABI.

Rust is just a bit less than 11 years old, C++ was 13 years old when screwed up std::string ABI, so, I think Rust has a few years yet to do less badly. Obviously it's easier to provide a stable ABI for say &'static [T] (a reference which lives forever to an immutable slice of T) or Option (either a positive 32-bit unsigned integer, or nothing) than for String (amortized growable UTF-8 text) or File (an open file some…

No? Rust has the 11 years C++ got to pick an ABI and then all the intervening years to see what they did wrong.
Post reply on HN