Author Topic: Support for c++20 modules  (Read 1561 times)

Offline sm0ke

  • Single posting newcomer
  • *
  • Posts: 2
Support for c++20 modules
« on: April 16, 2021, 11:40:29 pm »
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?

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13312
    • Travis build status
Re: Support for c++20 modules
« Reply #1 on: April 17, 2021, 01:00:26 am »
Probably but someone needs to research how to do it.
Do you use a compiler which supports the final/standard variant of modules?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline sm0ke

  • Single posting newcomer
  • *
  • Posts: 2
Re: Support for c++20 modules
« Reply #2 on: April 17, 2021, 04:25:24 am »
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
« Last Edit: April 17, 2021, 05:25:34 am by sm0ke »

Offline The_GTA

  • Multiple posting newcomer
  • *
  • Posts: 17
  • Developer & Entrepreneur
    • EirDev
Re: Support for c++20 modules
« Reply #3 on: May 11, 2021, 06:38:01 pm »
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". 👍😎
« Last Edit: May 11, 2021, 06:58:16 pm by The_GTA »

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13312
    • Travis build status
Re: Support for c++20 modules
« Reply #4 on: May 11, 2021, 06:48:45 pm »
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... :)
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline The_GTA

  • Multiple posting newcomer
  • *
  • Posts: 17
  • Developer & Entrepreneur
    • EirDev
Re: Support for c++20 modules
« Reply #5 on: May 11, 2021, 07:05:15 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.
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!  ;D

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.
« Last Edit: May 11, 2021, 07:14:29 pm by The_GTA »

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13312
    • Travis build status
Re: Support for c++20 modules
« Reply #6 on: May 11, 2021, 07:36:22 pm »
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.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline The_GTA

  • Multiple posting newcomer
  • *
  • Posts: 17
  • Developer & Entrepreneur
    • EirDev
Re: Support for c++20 modules
« Reply #7 on: May 11, 2021, 07:49:29 pm »
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.
« Last Edit: May 11, 2021, 07:51:56 pm by The_GTA »

Offline stahta01

  • Lives here!
  • ****
  • Posts: 7130
    • My Best Post
Re: Support for c++20 modules
« Reply #8 on: May 11, 2021, 07:56:31 pm »
For those like me who never heard of C++ import/export/module

https://en.cppreference.com/w/cpp/language/modules

Tim S.
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 32 bit.
On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13312
    • Travis build status
Re: Support for c++20 modules
« Reply #9 on: May 11, 2021, 08:05:01 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.
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.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline The_GTA

  • Multiple posting newcomer
  • *
  • Posts: 17
  • Developer & Entrepreneur
    • EirDev
Re: Support for c++20 modules
« Reply #10 on: May 11, 2021, 08:30:06 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) :)
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.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13312
    • Travis build status
Re: Support for c++20 modules
« Reply #11 on: May 11, 2021, 08:40:41 pm »
... 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.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]