Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Support for c++20 modules
The_GTA:
--- Quote from: oBFusCATed on May 11, 2021, 08:05:01 pm ---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) :)
--- End quote ---
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?
You mention use cases where there is no "good alternative to the preprocessor". If you care to mention them, then I can either confirm or deny your thought. Since the language does undergo drastic changes in recent days it is a good idea to reiterate on past experiences. ;)
--- Quote from: oBFusCATed on May 11, 2021, 08:05:01 pm ---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.
--- End quote ---
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.
About concepts, I very much like that language feature. Better compilation feedback by putting constraints into use of C++ templates is great to have. But I do not want to promote this feature. It is too much of a gimmick, a cherry pick by certain code scenarios. And if you are not a fan but a IDE developer, I can see how implementing IDE feedback for it can be annoying.
oBFusCATed:
--- Quote from: The_GTA on May 11, 2021, 08:30:06 pm ---... compilation speed of C++ is good...
--- End quote ---
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.
The core of C::B compiles for 1 minute on 8 core ryzen 1 CPU. The switch to wx3.0 made it slower. My guess is that the switch to using std::string/wstring for the implementation of wxString caused this.
Try to compile LLVM and tell me compilation speed is fast/good. Or try to link something to LLVM libraries and tell me that linking speed is fast (this is another artefact of language design).
I really hope you don't actually believe all these things you're stating in this topic. I really hope you're actively trolling. The world would be a better place if you're actually trolling. :) I'm out.
sm0ke:
I did some investigation.
MinGW-w64 version 9.0.0 from site https://winlibs.com/#download-release have modules support.
But Code::blocks have to be changed to compile .cpp files of project in a right order. I think resolving dependencies of .cpp files should consider some c++20 statements.
These are:
--- Code: ---export module _module_name_; // _module_name_ may differ from file name
--- End code ---
--- Code: ---import _module_name_;
--- End code ---
--- Code: ---export import _module_name_; // import things from given module and export them further
--- End code ---
Hard thing is that these statements can be not only in .cpp files, but in included .h files also.
Btw: MinGW-w64 when build modules creates folder "gcm.cache" in same place where 'project.cbp' file and makes '_module_name_.gcm' files for each module.
By now to build project that using modules I have to click: Build, Clean, Build. That is slows down process.
So dear developer of Code::Blocks please make new dependency system that allows to build .cpp files of project that uses modules in a right order.
oBFusCATed:
I don't think that just changing the deps system is the only obstacle to c++ module support.
As far as I know (I've done very limited reading on modules) there are things that need to be built.
At the moment and in the near future you would have to switch to another build system which supports them.
I think latest versions of cmake support it, which will allow you to still use C::B for your IDE.
cacb:
I support the idea of supporting modern C++ such as modules in Code::Blocks and in its build system.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version