Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Support for c++20 modules
The_GTA:
--- Quote from: oBFusCATed on May 11, 2021, 06:48:45 pm ---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.
--- End quote ---
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.
Slow compilation times is not a language problem but mainly how the compiler people implemented things. Visual Studio C++ has made huge leaps forward, I can attest to that through years of experience. Thus you should agree that the compilers do not deflect from the beauty of the language.
--- Quote from: oBFusCATed on May 11, 2021, 06:48:45 pm ---
--- Quote from: The_GTA on May 11, 2021, 06:38:01 pm ---Get on the module-hype-train now.
--- End quote ---
I think, I wait until it gets the module-just-works-train. :)
--- End quote ---
You are stubborn. But I like your conservative ways! ;D
--- Quote from: oBFusCATed on May 11, 2021, 06:48:45 pm ---p.s. your message looks like the messages produced by the spam bots... :)
--- End quote ---
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.
oBFusCATed:
--- Quote from: The_GTA on May 11, 2021, 07:05:15 pm ---Big engineering is the main idea behind new C++20 features.
--- End quote ---
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.
--- Quote from: The_GTA on May 11, 2021, 07:05:15 pm ---Leave no imaginable idea behind, break the old expectations with good language design.
--- End quote ---
C++ and good language design?
--- Quote from: The_GTA on May 11, 2021, 07:05:15 pm ---Slow compilation times is not a language problem but mainly how the compiler people implemented things.
--- End quote ---
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.
The_GTA:
--- Quote from: oBFusCATed on May 11, 2021, 07:36:22 pm ---
--- Quote from: The_GTA on May 11, 2021, 07:05:15 pm ---Slow compilation times is not a language problem but mainly how the compiler people implemented things.
--- End quote ---
The presence of the preprocessor is a language feature. The presence of the preprocessor is the major blocker to improved compiler/linker performance.
--- End quote ---
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.
If you want to hear another expert's take on this, head to this video (time 8:19) by Marc Gregoire.
--- Quote from: oBFusCATed on May 11, 2021, 07:36:22 pm ---Doing meta programming with recursive instantiation of functions/types is a language feature.
--- End quote ---
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 so don't lecture me on easily-inefficient but beautiful 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.
stahta01:
For those like me who never heard of C++ import/export/module
https://en.cppreference.com/w/cpp/language/modules
Tim S.
oBFusCATed:
--- Quote from: The_GTA on May 11, 2021, 07:49:29 pm ---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.
--- End quote ---
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.
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) :)
--- Quote from: The_GTA on May 11, 2021, 07:49:29 pm ---... so don't lecture me on ...
--- End quote ---
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.
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version