A big kudos to the C++ language team for this C++20 feature!It would have been big in 2011. Now it is just late and as always overdone/over-engineered and from what I'm hearing/reading it doesn't solve the biggest problem in C++ - slow compile times.
Get on the module-hype-train now.I think, I wait until it gets the module-just-works-train. :)
It would have been big in 2011. Now it is just late and as always overdone/over-engineered and from what I'm hearing/reading it doesn't solve the biggest problem in C++ - slow compile times.Big engineering is the main idea behind new C++20 features. Leave no imaginable idea behind, break the old expectations with good language design. But I can understand your sentiment. You do not have to join the hype. The old way does just work, and does solve the problems in an equivalent way.
You are stubborn. But I like your conservative ways! ;DGet on the module-hype-train now.I think, I wait until it gets the module-just-works-train. :)
p.s. your message looks like the messages produced by the spam bots... :)Good things deserve to be promoted, my friend. We are in this fight together. Also I do promote your IDE this way. I do post links to your website on my websites as well as social media. Have a fancy to deserved attention. Your IDE is the greatest cross-platform native development platform IMO.
Big engineering is the main idea behind new C++20 features.I don't know what this means, but C++ and C++20 in particular are just big compromises, well over-engineered things full of old mistakes no one is going to actually fix. I'm not sure I find anything useful in c++20, probably there are some small things, but the major features - nah. :) Hopefully modules aren't that bad when we start using them, but I doubt it would be soon.
Leave no imaginable idea behind, break the old expectations with good language design.C++ and good language design?
Slow compilation times is not a language problem but mainly how the compiler people implemented things.The presence of the preprocessor is a language feature. The presence of the preprocessor is the major blocker to improved compiler/linker performance.
You mention the preprocessor but you have to know that C++20 modules were made to decimate the use of the #include preprocessor statement, allowing for generation of PCH-style module compilation units, speeding up the compilation process! C++ is moving forward to allow faster compile times through smarter language features.Slow compilation times is not a language problem but mainly how the compiler people implemented things.The presence of the preprocessor is a language feature. The presence of the preprocessor is the major blocker to improved compiler/linker performance.
Doing meta programming with recursive instantiation of functions/types is a language feature.Pah. I would say: the problem is not the language, but the model of the programmer. And if the model is appropriate, then the compiler is at fault for not speeding up that use case. I myself have developed recursive parametrized meta-programmed matrix inversion based on cramer's rule (https://en.wikipedia.org/wiki/Cramer%27s_rule) so don't lecture me on easily-inefficient but beautiful (https://osdn.net/projects/magic-rw/scm/svn/blobs/head/rwlib/include/renderware.math.matview.h) code structures! Some problem solutions should really just be replaced by a non-meta-programmed thing that is layed-out by hand instead... Code does not have to complex! My point stands that the software model of the developer is the main fault why compilation is slow.
You mention the preprocessor but you have to know that C++20 modules were made to decimate the use of the #include preprocessor statement, allowing for generation of PCH-style module compilation units, speeding up the compilation process! C++ is moving forward to allow faster compile times through smarter language features.But the preprocessor cannot be disabled in C++20. It is still there and it is still used and it is still causing problems. And for some of the use cases there is no good alternative to the preprocessor. And we're 2021.
... so don't lecture me on ...I'm not lecturing you. I'm just stating facts. Your statement is that the language design doesn't affect compilation speed. I've mentioned two language features which does affect the compilation speed.
But the preprocessor cannot be disabled in C++20. It is still there and it is still used and it is still causing problems. And for some of the use cases there is no good alternative to the preprocessor. And we're 2021.The developer world does not change from day one. System headers, old libraries, OS-level features, cross language support: all these do and are going to depend on the preprocessor still. But I do not understand how the backwards compatibility of the C++ language can terribly affect your vision of a good modern language? So what if those language features with backwards compatibility in mind are the reason for slow compilation; your personal project can do better, right?
Func fact - the C++ committee is not 100% sure/convinced they would be able to convert the whole STL to the new module system. (at least the last time I've inspected the meeting mailings this was the case) :)
I'm not lecturing you. I'm just stating facts. Your statement is that the language design doesn't affect compilation speed. I've mentioned two language features which does affect the compilation speed.I consider painting a depressing picture quite the lecture. Your statement is that deprecated or bad use of the C++ language does make C++ compile slow. I don't disagree with this notion, but I find it very unfair. In general though, if willing to invest in a radically new C++20-based language, compilation speed of C++ is good. That is basically my point. Development experience distinguishes the good from the bad programmer, very significant so by the example of the C++ developer.
And for some things they don't have alternatives in the language, so you have to pay the price in compile time.
It seems concepts are another of those language features which does affect compilation speed.
... compilation speed of C++ is good...I hope you're joking. I spend my days waiting for the compiler. And our codebase at work is really fast to compile given how much code we have.
export module _module_name_; // _module_name_ may differ from file name
import _module_name_;
export import _module_name_; // import things from given module and export them further