41–50 of 143 posts
I can’t deploy C++ modules to any of the hardware I use in the shop. Probably won’t change in the near-to-mid future. It seems likely I’ll have to move away from C++, or perhaps more accurately it’s moving away from me.
why use modules if PCH on your diagram is not much worse in compile times?
Earlier quoted context omitted.
It's been the go-to syntax for 15 years now
Now I haven't touched C++ in probably 15 years but the definition of main() looks confused: > auto main() -> int Isn't that declaring the return type twice, once as auto and the other as int?
Earlier quoted context omitted.
Now I haven't touched C++ in probably 15 years but the definition of main() looks confused: > auto main() -> int Isn't that declaring the return type twice, once as auto and the other as int?
No. The auto there is doing some lifting so that you can declare the type afterwards. The return type is only defined once. There is, however, a return type auto-deduction in recent standards iirc, which is especially useful for lambdas. https://en.cppreference.com/w/cpp/language/auto.html auto f() -> int; // OK: f returns int auto g() { return 0.0; } // OK since C++14: g returns double auto h(); // OK since C++14: h…
auto g() -> auto { return 0.0; }
Here’s the thing I don’t get about module partitions: They only seem to allow one level of encapsulation. Program - Module - Module Partition whereas in module systems that support module visibility, like Rust’s, you can decompose your program at multiple abstraction levels: Program - Private Module - Private Module - Private Module - Public Module - Public Module Maybe I am missing something. It seems like you will…
Like most languages with modules. Rust, Modula-2 and Ada are probably the only ones with module nesting.
I can’t deploy C++ modules to any of the hardware I use in the shop. Probably won’t change in the near-to-mid future. It seems likely I’ll have to move away from C++, or perhaps more accurately it’s moving away from me.
If you tools are not updated that isn't the fault of C++. You will feel the same about Rust when forced to used a 15 year old version too (as I write this Rust 1.0 is only 10 years old). Don't whine to me about these problems, whine to your vendors until they give you the new stuff.
Just like Python was to blame for the horrible 2-to-3 switch, C++ is to blame for the poor handling of modules. They shouldn't have pushed through a significant backwards-incompatible change if the wide variety of vendor toolchains wasn't willing to adopt it.
C++ templates and metaprogramming is fundamentally incompatible with the idea of your code being treated in modules. The current solution chosen by compilers is to basically have a copy of your code for every dependency that wants to specialize something. For template heavy code, this is a combinatorial explosion.
It has worked perfectly fine while using VC++, minus the usual ICE that still come up.
It does not work very well at all if your goal is to port your current large codebase to incrementally use modules to save on compile time and intermediate code size.
I recently started a pet project using modules in MSVC, the compiler that at present has best support for modules, and ran into a compiler bug where it didn't know how to compile and asked me to "change the code around this line". So no, modules aren't even here, let alone to stay. Never mind using modules in an actual project when I could repro a bug so easily. The people preaching modules must not be using them ser…
> auto main() -> int { Dude…
From the outside looking in, this all feels like too little too late. Big tech has decided on Rust for future infrastructure projects. C++ will get QoL improvements… one day and the committees seem unable to keep everyone happy or disappoint one stake holder. C++ will be around forever, but will it be primarily legacy?
There literally isn't a plan or direction in place to add any way to compete with Rust in the safety space currently. They've got maybe until c++29 to standardise lifetimes, and then C++ will transition to a legacy language