5 ms·
C++26: more constexpr in the standard library
- nokeya 1y agoAnd in the wild (supported by all major compilers) we will see this somewhere around 2040…
- nly 1y agoNot if you run RHEL: dnf install gcc-toolset-X
- pjmlp 1y agoGCC only started supporting C++20 modules in a usable form, last month, and there are still parts missing from C++20. So expect at very least 2026 + 5 => 2031 for that command to provide a complete C++26 development experience.
- gpderetta 1y agoSure but this is about constexpr, not modules.
- mkoubaa 1y agoModules implicate the entire toolchain, backward compatibility, and binary compatibility. constexpr is a compiler feature. Wild that they are being compared.
- pjmlp 1y agoSee how many years it takes for a compiler on average to be 100% compliant after a standard is ratified, not widely at all when one wants to write portable code, regardless.
- int_19h 1y agoIn practice it's the same thing with C++ today as it is with web standards: you have to evaluate support on a feature-by-feature basis, and stick to the features that are supported on all the implementations you care about. And constexpr in stdlib is much more likely to get quick adoption across all implementations than something like modules.
- pjmlp 1y agoNot really, folks have done a good job turning the Web into ChromeOS, there is only one relevant browser still standing.
- pjmlp 1y agoIndeed, however there is a certain velocity how many years after the standard gets ratified until the compilers get fully compliant.
- ender341341 1y agoThe compiler writers have had a ton of issues implementing modules and aren't particularly excited for them (the committee seems to have forgot the lessens learned from c++98 and not having full implementations for crazy hard things) on the other hand constexpr changes tend to be picked up pretty quickly, and a lot of them tend to be things that the compiler/stl authors themselves are asking for.
- pjmlp 1y agoSince C++14 that I have increasingly changed my mind that it should only be about existing practice, and no paper should be accepted without implementation, regardless of how basic it may be, just like in other language ecosystems. Yes it might prevent lots of cool features, yet how good are they if it takes years to be implemented across compilers, or they turn out to be yet another export template. Additionally it would help to reduce count from those 300+ people, not everyone is there for good reasons, some only want to have a "contributed to C++" on their background, and then they are gone.
- ender341341 1y ago> should only be about existing practice, and no paper should be accepted without implementation When c++11 was still c++0x they made a big song and dance about how they wouldn't do another export template boondoggle and wanted an implementation available for any features. Then they seemed to have completely forget about it when doing modules (which not that surprisingly is running into similar issues that export templates did).
- deleted 1y ago[deleted]
- WalterBright 1y agoC++ should have just copied D modules (and the modules that ImportC supports).
- phire 1y agoYeah, maybe they should have, would have been a lot simpler. But C++ really wanted modules to be a more or less drop in replacement for #include (or at least a set of common use cases), which really pushed up the required level of complexity.
- pjmlp 1y agoThat it was already there via Apple and Google's work, header maps, but what we got was Microsoft proposal, after some collaboration with Google. Note at WWDC 2024, the module improvements regarding build times, in what concerns C++, it is based on header maps as well. Apple is not even bothering with C++20 modules.
- pjmlp 1y agoMaybe, however always telling what they should have done won't change the languages position on the market, so we get what we can have. Many things D might have done it first, yet it is hardly acknowledged, or has any impact on adoption without a major backer. I also keep telling WG14 should care about security, since Usenet days, fighting windmills.
- WalterBright 1y agoMany features of D have since found their way into C++, such as ranges, compile time function execution, thousands separators in numeric literals, conditional compilation blocks, etc.
- pjmlp 1y agoIndeed, and with them, the reasons for the industry to care about what D offers sadly diminishes. Also some of those features predate D, having shown first in Ada, Common Lisp, Eiffel, as discussed in the past.
- ratmeadow 1y agoAnd bug free, 2060. (Back in C++20 days I had a terrible habit of finding bugs in MSVC's implementations of metaprogramming features, after they claimed to be feature complete on C++20. Probably because people use these features less. Even now I occasionally receive emails about those bugs they've finally fixed.)
- brooke2k 1y agoseeing the words "constexpr sorting" makes all the compile-time sirens go off in my head
- mkoubaa 1y agoWe demand an opt out!
- WalterGR 1y ago8 days ago, 90+ comments: https://news.ycombinator.com/item?id=43775670 https://news.ycombinator.com/item?id=43775670
- username923409 1y agoThat's a different article
- dvratil 1y agoAmazing, now could I just get a way to do asynchronous network requests in two lines of code, like I have with other languages? Honestly, it seems to me like the committee is constantly chasing the easy bits but is failing to address the bigger issues in the language and, more importantly, the standard library.
- int_19h 1y agoco_await etc is there, now it's a matter of libraries picking that up. On Windows, you can do this today: auto response {co_await httpClient.GetStringAsync(uri)};
- lavalida 1y agoBoost.asio and Boost.cobalt both allow you to do this. You could even implement the coroutine traits yourself if you don't want to use these libraries.
- binary132 1y agoIt’s very different to ask for that from a language like Go or Python vs a language like C++. C++ is for interacting with system APIs and resources, on ANY system. Standardizing networking would require that every targetable host must have a common interface. Merely bridging win32, macos, bsd, android, and Linux is hard enough, without regard to all the possible platforms a C++ user might be interested in targeting. The more you add to the standard, the narrower the platform support gets. Should we also force C++ to only be able to target 64-bit hosts? How about requiring hardware vector support? See what I’m getting at? If you just want to make an async nw call, there are lots of things you can do that in already. If you want to write an async nw driver or library, then maybe you should use C++.
- EliRivers 1y agoSounds like you should use those other languages. Right tool for the right job.
- kubav027 1y agoOne of my first tasks in my carrier was implementing stable sort to incomplete stl implementation. In 3 years no one used it. This so niche it should not be part of C++ standard.
- gitroom 1y agolove seeing all the constant updates but sometimes i feel like the biggest pain points just stick around way too long - you ever feel like these standards chase the wrong problems sometimes?
- kreetx 1y agoWhat are the right problems?
- Davidbrcz 1y agoSanity, language complexity,
- Night_Thastus 1y ago"complex" isn't going anywhere. Complexity in languages only rises with age, and C++ has it especially because it's meant to be very general-purpose rather than specialized. Everyone uses C++ in different ways for different purposes, leading to additional complexity to keep everyone happy. "sanity" might refer to default behaviors. If it does, there's not a lot you can do there either. You can't go changing fundamentals of how the language works, because backwards compatibility is paramount. There would be riots if a new standard broke significant chunks of legacy code - even for the better.
- binary132 1y agosee Herb Sutter’s cppfront / cpp2 for a sane approach to sanity, IMO
- WalterBright 1y agoD does compile time function evaluation every time there's a ConstExpression in the grammar. It did this back in 2007. It required no changes to the grammar or syntax, it just enhanced constant folding to be able to do function calls. I don't understand why it is so complex in C++.
- kccqzy 1y agoI think being explicit is a good thing in C++. Suppose there is not constexpr in C++ and the following works: inline int foo(int x) { return x + 42; } int arr[foo(1)]; I think it would qualify as spooky action-at-a-distance if modifying foo causes arr to be malformed. And if they are in different libraries it restricts the ways the original function can be changed, making backwards compatibility slightly harder.
- tialaramex 1y agoThis would make more sense if constexpr was actually constant like say, Rust's const. The Rust const fn foo which gives back x + 42 for any x, is genuinely assured to be executed at compile time when given a constant parameter. If we modify the definition of foo so that it's not constant the compiler rejects our code. But C++ constexpr just says "Oh, this might be constant, or it might not, and, if it isn't don't worry about that, any constant uses will now magically fail to compile", exactly the spooky action at a distance you didn't want. When originally conceived it served more or less the purpose you imagine, but of course people wanted to "generalize" it to cover cases which actually aren't constant and so we got to where we are today.
- Calavar 1y agoSlapping the constexpr keyword on a function is useless by itself, but it becomes useful when you combine it with a constexpr or constinit variable. Which is not all that different from Rust: // C++ constexpr Foo bar() { /* ... */ } constexpr Foo CONSTANT = bar(); // Guaranteed to be evaluated at compile time constinit Foo VARIABLE = bar(); // Guaranteed to be evaluated at compile time // Rust const fn bar() -> Foo { /* ... */ } const CONSTANT: Foo = bar(); // Guaranteed to be evaluated at compile time static VARIABLE: Foo = bar(); // May or may not be evaluated at compile time So Rust is actually less powerful than C++ when it comes to non-constant globals because AFAIK it doesn't have any equivalent to constinit.