Support for c++20 modules

[sm0ke]

Hello, i like this IDE. But it's not allow to use modules in cpp.
Does the modules will be available by code::blocks in near future?

[oBFusCATed]

Probably but someone needs to research how to do it.
Do you use a compiler which supports the final/standard variant of modules?

[sm0ke]

I tried mingw64 snapshot version:
http://winlibs.com/
> GCC 11.0.1 snapshot 20210228 (experimental) + MinGW-w64 8.0.0 - release 1

It can compile modules when compile with "-fmodules-ts". But in the "export module _name;" _name should coincide with the file name. And file extension should be .cpp (not .ixx). Or it's not work.

Also... There is MSVC 19 Preview. Module file should be with .ixx extension (or with appropriate property).

Do not forget to recompile .cpp file that imports changed module. And module should be compiled before .cpp (or .h) file that its use. (make dependencies like with #include)

upd: I forgot to mention that clang can do with modules too, but it is too weird to configure to make it work.
clang i used from here:
http://winlibs.com/
GCC 10.3.0 + LLVM/Clang/LLD/LLDB 11.1.0 + MinGW-w64 8.0.0 - release 1

[The_GTA]

Hello sm0ke, I like your suggestion very much! Please add nice support for C++20 modules because they allow for advanced programming practices! This new C++ language feature enables very high-tech modern powerful development practices that can shape the future of native development in a significant way. Let me inspire you:

• to use modules the cruft of C-style header files is no longer mandatory! Header files are only a thing for compatibility with C-only projects or system headers. There is now a C++-language-level space of function signatures and symbols inside of compilation units that can be activated by pure inclusion of module units and activation with the "import" statement.
• a dependency tree where static modules depend on static modules is also possible, and much nicer so! Since you do not need header files anymore, you do not need to specify include directories for module-based C++ depedency projects anymore. This does remove nasty time-consuming project configuration steps. A big kudos to the C++ language team for this C++20 feature!
• how does Code::Blocks IDE know about function declarations and definitions in case that they come from modules, not from header files of the same compilation unit? Does Code::Blocks support looking up of such language structures from across compilation units, such as from imported module compilation units? I hope so. And consider the bigger picture: does Code::Blocks support looking up of language structures from compilation module units from static library dependencies? A very special case of such is the C++ standard runtime (STL).

Code::Blocks must not leave the modern developer crowd behind! Get on the module-hype-train now. Developers like me will have even more reasons to promote your product as the "IDE with all the features you need". 👍😎

[oBFusCATed]

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.

p.s. your message looks like the messages produced by the spam bots...

[The_GTA]

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.

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.

Get on the module-hype-train now.

I think, I wait until it gets the module-just-works-train.

You are stubborn. But I like your conservative ways! 

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.

[oBFusCATed]

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.
Doing meta programming with recursive instantiation of functions/types is a language feature.

[The_GTA]

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.

If you want to hear another expert's take on this, head to this video (time 8:19) by Marc Gregoire.

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 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]

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.
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)

... 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.
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.

[The_GTA]

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)

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. 

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.

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]

... 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.
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

Code

import _module_name_;

Code

export import _module_name_; // import things from given module and export them further

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.