131–140 of 437 posts
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.
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;
Earlier quoted context omitted.
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 tha…
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.
Earlier quoted context omitted.
The best thing the C++ WG could do is to spend an entire release cycle working on modules and packaging. 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…
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.
Earlier quoted context omitted.
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.
I have yet to see modules in the wild. What I have seen extensively are header-only projects.
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.
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.
Earlier quoted context omitted.
I have yet to see modules in the wild. What I have seen extensively are header-only projects.
You're not supposed to distribute the precompiled module file. You are supposed to distribute the source code of the module. 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. That prevents the compile-time bloat many header-only dependencies add. It also avoids distributing a `.cpp…
Earlier quoted context omitted.
>"For some types of applications it is actually the language of choice..." Can you give an example please? And how does it correspond to government ONCD report and other government docs "recommending" "safe" languages like: Rust (noted for its ability to prevent memory-unsafe code), Go, Java, Swift, C#, Ruby, Ada Among other things I design and implement high performance C++ backends. for some I got SOCS2 Type II cer…
It is the high-performance/high-scale data processing and storage engines for data-intensive applications, some of which are used in high-assurance environments. These are used outside of defense/intel (the data models are generic) but defense/intel tends to set the development standards for government since theirs are the strictest and most rigorous. An increasingly common requirement is the ability to robustly reje…
Would you be willing to share some more information about this? Interested in learning more since this sort of thing rarely seems to come up in typical situations I work in.
Earlier quoted context omitted.
The best thing the C++ WG could do is to spend an entire release cycle working on modules and packaging. 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.
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. It's the same with compilers, there's not one single implementation which is the compiler, and the ecosystem of compilers makes things more interesting.
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…
> 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. How far is Clang on reflection and contracts?
Clang’s C++2c implementation status page simply says “no” for both reflection and contracts. GCC’s says “yes”. https://clang.llvm.org/cxx_status.html https://gcc.gnu.org/projects/cxx-status.html