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.<p>Here's a quote from Bjarne,<p>> 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 harder problem. This is part of the standard proposal. Do we vote against the standard because there is a feature we think is bad? Because I think this one is bad. And that is a much harder problem. People vote yes because they think: "Oh we are getting a lot of good things out of this.", and they are right. We are also getting a lot of complexity and a lot of bad things. And this proposal, in my opinion is bloated committee design and also incomplete.
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 that — see e.g. Ada Spark.
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 cannot even start to think about proof of correctness.
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.
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.<p>C++ will never, ever be modern and comprehensible because of 1 and 1 reason alone: backward compatibility.<p>It does not matter what version of C++ you are using, you are still using C with classes.
The people who did contracts are aware of ada/spark and some have experience using it. Only time will tell if it works in c++ but they at least did all they could to give it a chance.<p>Note that this is not the end of contrats. This is a minimun viable start that they intend to add to but the missing parts are more complex.
> Programming languages used for correct-by-design software (Ada, C++, Rust) ...<p>A shoutout to Eiffel, the first "modern" (circa 1985) language to incorporate Design by Contract. Well done Bertrand Meyer!
Right, I think the tension here is that we would like contracts to exist in the language, but the current design isn't what it needs to be, and once it's standardized, it's extremely hard to fix.
The devil is in the details, because standardization work is all about details.<p>From my outside vantage point, there seems to be a few different camps about what is desired for contracts to even <i>be</i>. The conflict between those groups is why this feature has been contentious for... a decade now?<p>Some of the pushback against this form of contracts is from people who desire contracts, but don't think that this design is the one that they want.
But why? You can do everything contracts do in your own code, yes? Why make it a language feature? I'm not against growing the language, but I don't see the necessity of this specific feature having new syntax.
Pre- and postconditions are actually part of the function signature, i.e. they are visible to the caller. For example, static analyzers could detect contract violations just by looking at the callsite, without needing access to the actual function implementation. The pre- and postconditions can also be shown in IDE tooltips. You can't do this with your own contracts implementation.<p>Finally, it certainly helps to have a standardized mechanisms instead of everyone rolling their own, especially with multiple libraries.
Contracts are about specifying static properties of the system, not dynamic properties. Features like assert /check/ (if enabled) static properties, at runtime. static_assert comes closer, but it’s still an awkward way of expressing Hoare triples; and the main property I’m looking for is the ability to easily extract and consider Hoare triples from build-time tooling. There are hacky ways to do this today, but they’re not unique hacky ways, so they don’t compose across different tools and across code written to different hacks.
The common argument for a language feature is for standardization of how you express invariants and pre/post conditions so that tools (mostly static tooling and optimizers) can be designed around them.<p>But like modules and concepts the committee has opted for staggered implementation. What we have now is effectively syntax sugar over what could already be done with asserts, well designed types and exceptions.
DYI contracts don't compose when mixing code using different DYI implementations. Some aspects of contracts have global semantics.
That's a genius idea, keep adding broken stuff into the standard until there's no choice but to break compatibility to fix it.
C++ contracts standardizes what people already do in C++. Where is the complexity in that? It removes the need to write your own implementation because the language provides a standard interoperable one.<p>An argument can be made that C++26 features like reflection add complexity but I don't follow that argument for contracts.
Just because Bjarne thinks the feature is bad doesnt mean it is bad. He can be wrong. The point is, most peoppe disagree with him, and so a lot of peoppe do think it is good.
There have been several talks about contracts and the somewhat hidden complexities in them. C++ contracts are not like what you'd initally expect. Compiler switches can totally alter how contracts behave from getting omitted to reporting failures to aborting the program. There is also an optional global callback for when a contract check fails.<p>Different TUs can be compiled with different settings for the contract behavior. But can they be binary compatible? In general, no. If a function is declared in-line in a header, the comoiler may have generated two different versions with different contract behaviors, which violates ODR.<p>What happens if the contract check calls a helper function that throws an exception?<p>The whole things is really, really complex and I don't assume that I understand it properly. But I can see that there are some valid concerns against the feature as standardized and that makes me side with the opposition here: this was not baked enough yet
That sounds like the worst kind of misfeature.<p>It sounds like it should solve your problem. At first it seems to work. Then you keep on finding the footguns after it is too late to change the design.
Coroutines went through the same cycle. Standardized in C++20, and I still hit compiler-specific differences in how symmetric transfer gets lowered.
>to a language which has already surpassed its complexity budget<p>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.
Source of quote:<p><a href="https://youtu.be/tzXu5KZGMJk?t=3160" rel="nofollow">https://youtu.be/tzXu5KZGMJk?t=3160</a>
Has any project ever tried to quantify a “complexity budget” and stick to it?<p>I’m fascinated by the concept of deciding how much complexity (to a human) a feature has. And then the political process of deciding what to remove when everyone agrees something new needs to be accepted.
I mean... it's C++. The complexity budget is like the US government's debt ceiling.
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.
Well thats not always true. Initializer list is a glaring example. So are integer promotion some other things like
Without a significant amount of needed context that quote just sounds like some awkward rambling.<p>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.<p>I can hardly think of any major feature added to the language that didn't introduce a great deal of footguns, unintended consequences, significant compilation performance issues... to single out contracts is unusual to say the least.
The "erroneous behavior" redefinition for reads of uninitialized variables is really interesting: <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2795r5.html" rel="nofollow">https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p27...</a><p>It does have a runtime cost. There's an attribute to force undefined behavior on read again and avoid the cost:<p><pre><code> int x [[indeterminate]];
std::cin >> x;</code></pre>
Hm, I wonder if this will be a compiler flag too, probably yes, since some projects would prefer to init all variables by hand anyway.
This is awesome. I've was a dev on the C++ team at MS in the 90s and was sure that RTTI was the closest the language would ever get to having a true reflection system.
> Second, conforming compiler and standard library implementations are coming quickly. Throughout the development of C++26, at any given point both GCC and Clang had already implemented two-thirds of C++26 features. Today, GCC already has reflection and contracts merged in trunk, awaiting release.<p>How far is Clang on reflection and contracts?
Biggest open question is whether the small changes to the module system in this standard will actually lead to more widespread adoption
The best thing the C++ WG could do is to spend an entire release cycle working on modules and packaging.<p>It's nice to have new features, but what is really killing C++ is Cargo. I don't think a new generation of developers are going to be inspired to learn a language where you can't simply `cargo add` whatever you need and instead have to go through hell to use a dependency.
To me, the most important feature of Cargo isn't even the dependency management but that I don't ever need to tell it which files to compile or where to find them. The fact that it knows to look for lib.rs or main.rs in src and then recursively find all my other modules without me needing to specify targets or anything like that is a killer feature on its own IMO. Over the past couple of years I've tried to clone and build a number of dotnet packages for various things, but for an ecosystem that's supposedly cross-platform, almost none of them seem to just work by default when I run `dotnet build` and instead require at least some fixes in the various project files. I don't think I've ever had an issue with a Rust project, and it's hard not to feel like a big part of that is because there's not really much configuration to be done. The list of dependencies is just about the only thing in there that effects the default build; if there's any other configuration other than that and the basic metadata like the name, the repo link, the license, etc., it almost always will end up being specifically for alternate builds (like extra options for release builds, alternate features that can be compiled in, etc.).
<i>> The fact that it knows to look for lib.rs or main.rs in src and then recursively find all my other modules without me needing to specify targets or anything like that is a killer feature on its own IMO.</i><p>In the interest of pedantry, locating source files relative to the crate root is a language-level Rust feature, not something specific to Cargo. You can pass any single Rust source file directly to rustc (bypassing Cargo altogether) and it will treat it as a crate root and locate additional files as needed based on the normal lookup rules.
Interesting, I didn't realize this! I know that a "crate" is specifically the unit of compilation for rustc, but I assumed there was some magic in cargo that glued the modules together into a single AST rather than it being in rustc itself.<p>That being said, I'd argue that the fact that this happens so transparently that people don't really need to know this to use Cargo correctly is somewhat the point I was making. Compared to something like cmake, the amount of effort to use it is at least an order of magnitude lower.
> I don't think I've ever had an issue with a Rust project, and it's hard not to feel like a big part of that is because there's not really much configuration to be done.<p>For most crates, yes. But you might be surprised how many crates have a build.rs that is doing more complex stuff under the hood (generating code, setting environment variables, calling a C compiler, make or some other build system, etc). It just also almost always works flawlessly (and the script itself has a standardised name), so you don't notice most of the time.
True, but if anything, a build.rs is a lot easier for me to read and understand (or even modify) if needed because I already know Rust. With something like cmake, the build configuration is an entirely separate language the one I'm actually working in, and I haven't seen a project that doesn't have at least <i>some</i> amount of custom configuration in it. Starting up a cargo project literally doesn't require putting anything in the Cargo.toml that doesn't exist after you run `cargo new`.
Yep ... go/zig pkg management has the same benefit compared to c/c++.
For me the lack of dependency hell until I hit a c/c++ component somewhere in the build is the real winner.
I’m still surprised how people ignore Meson. Please test it :)<p><a href="https://mesonbuild.com/" rel="nofollow">https://mesonbuild.com/</a><p>And Mesons awesome dependency handling:<p><a href="https://mesonbuild.com/Dependencies.html" rel="nofollow">https://mesonbuild.com/Dependencies.html</a><p><a href="https://mesonbuild.com/Using-the-WrapDB.html#using-the-wrapdb" rel="nofollow">https://mesonbuild.com/Using-the-WrapDB.html#using-the-wrapd...</a><p><a href="https://nibblestew.blogspot.com/2026/02/c-and-c-dependencies-dont-dream-it-be-it.html" rel="nofollow">https://nibblestew.blogspot.com/2026/02/c-and-c-dependencies...</a><p>I suffered with Java from
Any, Maven and Gradle (the oldest is the the best). After reading about <i>GNU Autotools</i> I was wondering why the C/C++ folks still suffer? Right at that time Meson appeared and I skipped the suffering.<p><pre><code> * No XML
* Simple to read and understand
* Simple to manage dependencies
* Simple to use options
</code></pre>
Feel free to extend WrapDB.
Meson is indeed nice, but has very poor support for GPU compilation compared to CMake. I've had a lot of success adopting the practices described in this talk, <a href="https://www.youtube.com/watch?v=K5Kg8TOTKjU" rel="nofollow">https://www.youtube.com/watch?v=K5Kg8TOTKjU</a>. I thought I knew a lot of CMake, but file sets definitely make things a
lot simpler.
Meson merges the crappy state of C/C++ tooling with something like Cargo in the worst way possible: by forcing you to handle the complexity of both. Nothing about Meson is simple, unless you're using it in Rust, in which case you're better off with Cargo.<p>In C++ you don't get lockfiles, you don't get automatic dependency install, you don't get local dependencies, there's no package registry, no version support, no dependency-wide feature flags (this is an incoherent mess in Meson), no notion of workspaces, etc.<p>Compared to Cargo, Meson isn't even in the same galaxy. And even compared to CMake, Meson is yet another incompatible incremental "improvement" that offers basically nothing other than cute syntax (which in an era when AI writes all of your build system anyway, doesn't even matter). I'd much rather just pick CMake and move on.
Build system generators (like Meson, autotools, CMake or any other one) can't solve programming language module and packaging problems, even in principle. So, it's not clear what your argument is here.<p>> I’m still surprised how people ignore Meson. Please test it :)<p>I did just that a few years ago and found it rather inconvenient and inflexible, so I went back to ignoring it. But YMMV I suppose.<p>> After reading about GNU Autotools<p>Consider Kitware's CMake.
Agreed, arcane cmake configs and or bash build scripts are genuinely off-putting. Also cpp "equivalents" of cargo which afaik are conan and vcpkg are not default and required much more configuring in comparison with cargo. Atleast this was my experience few years ago.
It's fundamentally different; Rust entirely rejects the notion of a stable ABI, and simply builds everything from source.<p>C and C++ are usually stuck in that antiquated thinking that you should build a module, package it into some libraries, install/export the library binaries and associated assets, then import those in other projects. That makes everything slow, inefficient, and widely dangerous.<p>There are of course good ways of building C++, but those are the exception rather than the standard.
"Stable ABI" is a joke in C++ because you can't keep ABI and change the implementation of a templated function, which blocks improvements to the standard library.<p>In C, ABI = API because the declaration of a function contains the name and arguments, which is all the info needed to use it. You can swap out the definition without affecting callers.<p>That's why Rust allows a stable C-style ABI; the definition of a function declared in C doesn't have to be in C!<p>But in a C++-style templated function, the caller needs access to the <i>definition</i> to do template substitution. If you change the definition, you need to recompile calling code i.e. ABI breakage.<p>If you <i>don't</i> recompile calling code and link with other libraries that are using the new definition, you'll violate the one-definition rule (ODR).<p>This is bad because duplicate template functions are pruned at link-time for size reasons. So it's a mystery as to what definition you'll get. Your code will break in mysterious ways.<p>This means the C++ committee can never change the implementation of a standardized templated class or function. The only time they did was a minor optimization to std::string in 2011 and it was such a catastrophe they never did it again.<p>That is why Rust will not support stable ABIs for any of its features relying on generic types. It is impossible to keep the ABI stable and optimize an implementation.
> C and C++ are usually stuck in that antiquated thinking that you should build a module, package it into some libraries, install/export the library binaries and associated assets, then import those in other projects. That makes everything slow, inefficient, and widely dangerous.<p>It seems to me the "convenient" options are the dangerous ones.<p>The traditional method is for third party code to have a stable API. Newer versions add functions or fix bugs but existing functions continue to work as before. API mistakes get deprecated and alternatives offered but newly-deprecated functions remain available for 10+ years. With the result that you can link all applications against any sufficiently recent version of the library, e.g. the latest stable release, which can then be installed via the system package manager and have a manageable maintenance burden because only one version needs to be maintained.<p>Language package managers have a tendency to facilitate breaking changes. You "don't have to worry" about removing functions without deprecating them because anyone can just pull in the older version of the code. Except the older version is no longer maintained.<p>Then you're using a version of the code from a few years ago because you didn't need any of the newer features and it hadn't had any problems, until it picks up a CVE. Suddenly you have vulnerable code running in production but fixing it isn't just a matter of "apt upgrade" because no one else is going to patch the version only you were using, and the current version has several breaking changes so you can't switch to it until you integrate them into your code.
This is all wishful thinking disconnected from practicalities.<p>First you confuse API and ABI.<p>Second there is no practical difference between first and third-party for any sufficiently complex project.<p>Third you cannot have multiple versions of the same thing in the same program without very careful isolation and engineering. It's a bad idea and a recipe for ODR violations.<p>In any non-trivial project there will be complex dependency webs across different files and subprojects, and humans are notoriously bad at packaging pieces of code into sensible modules, libraries or packages, with well-defined and maintained boundaries. Being able to maintain ABI compatibility, deprecating things while introducing replacement etc. is a massive engineering work and simply makes people much less likely to change the way things are done, even if they are broken or not ideal. That's an effort you'll do for a kernel (and only on specific boundaries) but not for the average program.
It's not true that Rust rejects "the notion of a stable ABI". Rust rejects the C++ solution of freeze everything and hope because it's a disaster, it's less stable than some customers hoped and yet it's frozen in practice so it disappoints others. Rust says an ABI should be a promise by a developer, the way its existing C ABI is, that you can <i>explicitly</i> make or not make.<p>Rust is interested in having a properly thought out ABI that's nicer than the C ABI which it supports today. It'd be nice to have say, ABI for slices for example. But "freeze everything and hope" isn't that, it means every user of your language into the unforeseeable future has to pay for every mistake made by the language designers, and that's already a sizeable price for C++ to pay, "ABI: Now or never" spells some of that out and we don't want to join them.
> It'd be nice to have say, ABI for slices for example.<p>The de-facto ABI for slices involves passing/storing pointer and length separately and rebuilding the slice locally. It's hard to do better than that other than by somehow standardizing a "slice" binary representation across C and C-like languages. And then you'll still have to deal with existing legacy code that doesn't agree with that strict representation.
I would suggest importing binaries and metadata is going to be faster than compiling all the source for that.
You'd be wrong. If the build system has full knowledge on how to build the whole thing, it can do a much better job. Caching the outputs of the build is trivial.<p>If you import some ready made binaries, you have no way to guarantee they are compatible with the rest of your build or contain the features you need. If anything needs updating and you actually bother to do it for correctness (most would just hope it's compatible) your only option is usually to rebuild the whole thing, even if your usage only needed one file.
"That makes everything slow, inefficient, and widely dangerous."<p>There nothing faster and more efficient than building C programs. I also not sure what is dangerous in having libraries. C++ is quite different though.
Of course there is. Raw machine code is the gold standard, and everything else is an attempt to achieve _something_ at the cost of performance, C included, and that's even when considering whole-program optimization and ignoring the overhead introduced by libraries. Other languages with better semantics frequently outperform C (slightly) because the compiler is able to assume more things about the data and instructions being manipulated, generating tighter optimizations.
ODR violations are very easy to trigger unless you build the whole thing from source, and are ill-formed, no diagnostic required (worse than UB).
>There are of course good ways of building C++, but those are the exception rather than the standard.<p>What are the good ways?
Build everything from source within a single unified workspace, cache whatever artifacts were already built with content-addressable storage so that you don't need to build them again.<p>You should also avoid libraries, as they reduce granularity and needlessly complexify the logic.<p>I'd also argue you shouldn't have any kind of declaration of dependencies and simply deduce them transparently based on what the code includes, with some logic to map header to implementation files.
The problem is doing this requires a team to support it that is realistically as large as your average product team. I know Bazel is the solution here but as someone who has used C++, modified build systems and maintained CI for teams for years, I have never gotten it to work for anything more than a toy project.
>Build everything from source within a single unified workspace, cache whatever artifacts were already built with content-addressable storage so that you don't need to build them again.<p>Which tool do you use for content-addressable storage in your builds?<p>>You should also avoid libraries, as they reduce granularity and needlessly complexify the logic.<p>This isn't always feasible though.<p>What's the best practice when one cannot avoid a library?
You can use S3 or equivalent; a normal filesystem (networked or not) also works well.<p>You hash all the inputs that go into building foo.cpp, and then that gives you /objs/<hash>.o. If it exists, you use it; if not, you build it first. Then if any other .cpp file ever includes foo.hpp (directly or indirectly), you mark that it needs to link /objs/<hash>.o.<p>You expand the link requirements transitively, and you have a build system. 200 lines of code. Your code is self-describing and you never need to write any build logic again, and your build system is reliable, strictly builds only what it needs while sharing artifacts across the team, and never leads to ODR.
"Do not do it" looks like the winning one nowadays.
I may be in the minority but I like that C++ has multiple package managers, as you can use whichever one best fits your use case, or none at all if your code is simple enough.<p>It's the same with compilers, there's not one single implementation which is <i>the</i> compiler, and the ecosystem of compilers makes things more interesting.
Multiple package managers is fine, what's needed is a common repository standard (or even any repository functionality at all). Look at how it works in Java land, where if you don't want to use Maven you can use Gradle or Bazel or what have you, or if you hate yourself you can use Ant+Ivy, but all of them share the same concept of what a dependency is and can use the same repositories.
Also, having one standard packaging format and registry doesn't preclude having alternatives for special use cases.<p>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.<p>The important thing is to get one system blessed as The C++ Package Format by the standard to avoid xkcd 927 issues.
In my experience, no one does build systems right; Cargo included.<p>The standard was initially meant to standardize existing practice. There is no good existing practice. Very large institutions depending heavily on C++ systematically fail to manage the build properly despite large amounts of third party licenses and dedicated build teams.<p>With AI, how you build and integrate together fragmented code bases is even more important, but someone has yet to design a real industry-wide solution.
I didn’t think header only was that bad - now we have a nightmare of incompatible standards and compilers.
No, because most major compilers don't support header units, much less standard library header units from C++26.<p>What'll spur adoption is cmake adopting Clang's two-step compilation model that increases performance.<p>At that point every project will migrate overnight for the huge build time impact since it'll avoid redundant preprocessing. Right now, the loss of parallelism ruins adoption too much.
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.
No idea if modules themselves are failed or no, but if c++ wants to keep fighting for developer mindshare, it must make something resembling modules work and figure out package management.<p>yes you have CPM, vcpkg and conan, but those are not really standard and there is friction involved in getting it work.
Much like contracts--yes, C++ needs something modules-like, but the actual design as standardized is not usable.<p>Once big companies like Google started pulling out of the committee, they lost their connection to reality and now they're standardizing things that either can't be implemented or no one wants as specced.
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.<p>Neither of those things require modules as currently defined.
Can you explain why you think modules are a failed idea? Because not that many use them right now?<p>Personally I use them in new projects using XMake and it just works.
I'm not the PC but I think you miss most of the pain points due to: 'personal' projects.<p>There's not a compatible format between different compilers, or even different versions of the same compiler, or even the same versions of the same compiler with different flags.<p>This seems immediately to create too many permutations of builds for them to be distributable artifacts as we'd use them in other languages. More like a glorified object file cache. So what problem does it even solve?
Because as a percentage of global C++ builds they’re used in probably 0.0001% of builds with no line of sight to that improving.<p>They have effectively zero use outside of hobby projects. I don’t know that any open source C++ library I have ever interacted with even pretends that modules exist.
"Failed idea" gives modules too much credit. Outside old codebases, almost no one outside C++ diehards have the patience for the build and tooling circuss they create, and if you need fast iteration plus sane integration with existing deps, modules are like trading your shoes for roller skates in a gravel lot. Adopting them now feels like volunteering to do tax forms in assembbly.
I frankly wish we'd stop developing C++. It's so hard to keep track of all the new unnecessary toys they're adding to it. I thought I knew C++ until I read some recent C++ code. That's how bad it is.<p>Meanwhile C++ build system is an abomination. Header files should be unnecessary.
Finally, reflection has arrived, five years after I last touched a line in c++. I wonder how long would it take the committee, if ever, to introduce destructing move.
I am actually excited for post and pre conditions. I think they are an underused feature in most languages.
I switched from C++ to Java/Python 20 years ago. I never really fit in, I just dont understand when people talk about the complicated frameworks to avoid multithreading/mutexes etc when basic C++ multi threading is much simpler than rxjava or async/await or whatever is flavor of the month.<p>But C++ projects are usually really boring. I want to go back but glad I left. Has anyone found a place where C++ style programming is in fashion but isn't quite C++? I hope that makes sense.
std::execution is very interesting, but will be difficult to get started with, as cautioned by Sutter. This HPC Wire article demonstrates how to use standard C++ to benefit from asynchronously parallel computation on both CUDA and MPI:<p><a href="https://www.hpcwire.com/2022/12/05/new-c-sender-library-enables-portable-asynchrony/" rel="nofollow">https://www.hpcwire.com/2022/12/05/new-c-sender-library-enab...</a><p>Overlapping communication and computation has been a common technique for decades in high-performance computing to "hide latency", which leads to better scaling. Now standard C++ can be used to express parallel algorithms without tying to a specific scheduler.
I don't care until they stop pretending Unicode doesn't exist.
What are you talking about, there is actually too much unicode awareness in C++. Unicode is not the same thing as utf-8. And, frankly, no language does it right, I'm not even sure "right" exists with Unicode
Great. C++20 has been my favorite and I was wasn't sure what the standards says since it's been a while. I'll be reading the C++26 standard soon
If you ask me (and why wouldn't you? :-)...) I really wish the C++ WG would do several things:<p>1. Standardize a `restrict` keyword and semantics for it (tricky for struct/class fields, but should be done).<p>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 particularly. And while we're at it, let us us a class' name as a namespace for static methods, so that Obj::f the static method is simply the method f in namespace Obj.<p>3. Get compiler makers to have an ABI break, so that we can do things like passing wrapped values in registers rather than going through memory. See: <a href="https://stackoverflow.com/q/58339165/1593077" rel="nofollow">https://stackoverflow.com/q/58339165/1593077</a><p>4. Get rid of the current allocators in the standard library, which are type-specific (ridiculous) and return pointers rather than regions of memory. And speaking of memory regions (i.e. with address and size but no element type) - that should be standardized too.
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.<p>This should be your default stack on any small-to-medium sized C++ project.<p>Bazel, the default pick for very large codebases, also has support for C++20 modules.
Thanks. It's been a long time since I started a C++ project, and I've never set up any build chain in Visual Studio or Xcode other than the default.
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]<p>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.<p>[1] <a href="https://gitlab.kitware.com/cmake/cmake/-/work_items/27706" rel="nofollow">https://gitlab.kitware.com/cmake/cmake/-/work_items/27706</a>
You're not supposed to distribute the precompiled module file. You are supposed to distribute the source code of the module.<p>Header-only projects are the best to convert to modules because you can put the implementation of a module in a "private module fragment" in that same file and make it invisible to users.<p>That prevents the compile-time bloat many header-only dependencies add. It also avoids distributing a `.cpp` file that has to be compiled and linked separately, which is why so many projects are header-only.
How about using Zig to build C++ projects?
I haven't used it.<p>That being said, while it <i>looks</i> better than CMake, for anything professional I need remote execution support to deviate from the industry standard. Zig doesn't have that.<p>This is because large C++ projects reach a point where they cannot be compiled locally if they use the full language. e.g. Multi-hour Chromium builds.
Sadly, transparent hash strings for unordered_map are out.
I look forwards to getting to make use of this in 2040!<p>Proper reflection is exciting.
GCC has it marked as 'RESOLVED FIXED' as of about a week and a half ago. So, it's coming.<p>Also, useful: <a href="https://gcc.gnu.org/projects/cxx-status.html" rel="nofollow">https://gcc.gnu.org/projects/cxx-status.html</a>
I am curious what is their strategy to get language to the stage where the US government will make it cosher for new projects
"Japanese soldier who kept fighting 29 years after World War 2"
[flagged]
Contracts feel like the right direction but the wrong execution timeline. The Ada/SPARK model shows how powerful contracts become when they feed into static verification — but that took decades of iteration on a language with far cleaner semantics. Bolting that onto C++ where UB is load-bearing infrastructure is a different beast entirely.
The real risk isn't complexity for complexity's sake — it's that a "minimum viable" contracts spec gets locked in, and then the things that would actually make it useful for proof assistants become impossible to retrofit because they'd break the v1 semantics. Bjarne's concern about "incomplete" is more worrying to me than "bloated."