Awesome! I've been looking for a good first talk on modules and in particular what I can do right now. The standard is very nice, but it seems a lot of module features haven't been implemented yet, which makes it quite annoying when I watch a lot of talks, they don't take that into account.
A small error on the slides: The CMake FILE_SET for modules sources is called CXX_MODULES, not MODULES. Also, on slide #20 about interface partitions, the names of the module in the primary module interface and the partitions need to be consistent (either all 'm' or all 'mice', but not a mixture of the two).
@@iliasalaur They didn't try to work against the root of all this problems. Single translation units. A 1970s concept that is so wrong. We could have so much nice things if we could get of command line compilers and obj files, instead go with a server that get feed c++ source files and spits out executables. Thats the solution for the speed problem. The better abstraction could be solved by allowing open classes. Objective-C++ is doing it very well but only for the Objective-C.object model.
this reminds me of a helmet that i had that had a hammer attached to it. So everytime i want to nail something to the wall, i would wear that helmet and swing my head around to hit the nail. but sometimes i miss and i hit my head against the wall instead. So to solve that problem, i added some padding to my forehead. now everything works like a charm.
Happy to have learnt through this talk how to export templates. I was putting the export on the function "part" and couldn't figure out why it wasn't working.
At this time (version 17.8.6) Visual Studio can with no problem have modules that wrap header files that include the C standard library. So, no problem if you write a module that uses a C library. That's already a big deal. It won't work if you include a header that includes the C++ standard library. So if you try to wrap a C++ library that won't work because the library will include stuff from the C++ standard library and you will get name clashes. So, the solution is to have an immediate wrapper module that just includes all standard library headers that are used by the wrapped library in the bit between module; and export module x;. and then exports the library. In most cases that will probably approach most of the C++ standard library. At least it's a trick that works (I verified with a minimal example). Hopefully this issue will be resolved and the trick will no longer be needed soon.
Aside of CMake (as of 3.28) modules support by toolchains is very lacking. Neither Apple's clang 15.0 nor gcc 13.2 provide a dependency graph for CMake. clang 17.0 works somewhat with CMake (i.e. it configures and builts everything), but then VS Code can't handle dependencies and code completion, neither with the C/C++ plugin nor the clangd plugin. So for the time being it seems we have to wait for the tools to adopt still. "Getting started today"? No way.
Only if you compare it with single vendor programming languages - rust, swift,... - that mandate (and provide) the build system. For those of us in embedded and system programming world we can't rely on those languages. We need C/C++ because it integrates with our systems, not finding a way to get those single vendors to care enough to support our system. Complexity is the price we pay for flexibility, but in return we can ship product.
@@_ironrose Unfortunately yes. But we must remember that C++ is the only language out there that does not force programmers to write their software in any specific way. All C++ does is give us a set of tools and some loose guidelines. Rust assumes programmers can't be trusted and so places as many restrictions as possible. C++ is getting better, sure, but due to legacy reasons it has a lot of "catching up" to do. Modules make C++ almost infinitely better.
I don't like the fact imports are dumped into the current namespace. Perhaps if it was a bit more python-y in the way of : import B; B.my_import_func(); in lieu of a using declaration would provide a much cleaner namespace .
Namespaces help a little in foo.cpp: export module foo; namespace foo { export void fn(){} } in main.cpp import foo; int main() { foo::fn() } This interface only requires that all your modules have a namespace that is the same as the name it uses when calling export.
Is 17:53 correct? My compiler thinks that the implementaiton module is trying to import itself. Oh wait, the code is correct but the compilation order is crucial, as was not mentioned. 21:29 should the "m:" twice be "mice:"?
I'm using visual studio and start to learn modules. The thing is there is bad tutorial on the internet. I import std module to other module that is in project which compile to static library (.lib). In that project I'm only using print function from cpp23. The lib file is about 4mb of size when using imported std. If this is normal? All library contining cpp standard library is linked to my library? Second, if I will link my library with other project that make executable file (.exe) and in that project I'm using cpp standard library (import std) ofcourse I' have to use std.ifc interface again but do I have link c++ standard library (.lib) files again? This is very practical information..not only to show how "nice" is write "import std".
Great talk, thanks! Some concepts here, like "export import", "export using", and the ability to export a function returning a non-exported type, make me a bit worried for the future of C++. A lot of people already get confused with headers, and this is IMO adding a whole lot of complexity. That doesn't matter for people who know what they're doing, but this just makes it harder to convince large teams / companies to use modern C++.
Exporting from module partitions is not a standard. GCC and Clang do not support it, and Clang developers have even said that it might never be supported! I would add a BIG NOTE at slide 20.
Why would this be a good idea? A module is simply a translation unit. I think the approach of linking several module interface units together into a library is a much better solution. After all, a library may be formed from just a single TU.
Sorry for being imprecise there. The 19.34 is the C++ toolchain version, the number you get when running cl.exe, not the version number of the Visual Studio IDE that you get in the About... window in Visual Studio.
It's too complicated. As a long term C++ dev, I really was hoping that C++ modules would ease my life and the one of my team. It's 2024 and I don't see the benefits of it so much: too verbose, error prone.. it's depressing because we had to set a new modern language in our stack because of my failure to predict what modules would end up like. My fault, but it kills me.
It will ease your life. At least I think so. Stick to module interface units for declarations and documentation, and module implementation units for definitions. You never need to worry about inclusion hell again. I would say that's a big win.
Modules were such a wasted opportunity to make something good, ended up ugly and overly verbose with so many rules to remember. Nobody will use, like coroutines.
Coroutines are already usable, although there are more libraries needed in the ecosystem. Asio already makes good use of them for async networking. Writing your own coroutine type is much harder, but most people don't need to do that.
Coroutines is a very different story, because there is a very small number of scenarios, where they could be handy. Modules are exactly the opposite. This is the piece of standard, that must be used everywhere. I hope that in 2-3 years more compilers will add support for them, because you know, headers - suck
Coroutines are hard to implement, but easy to use. They are not meant to be implemented by everyone, only library implementers will need to do that, and then millions of C++ developers will be able to use them without knowing the implementation details.
@@iliasalaur I love headers. I love them much more then all the languages that mix the implementation with the declarations.The problem is not hte header but the single translation unit compilation speed (and some better implementation hidding). All of it could have been solved much better without this module system they came up with.
Coroutines have myriad possible uses. I have used coroutines in Unity for a variety of uses. Anywhere you have async code you can use coroutines and they have a simple intuitive syntax there. You shouldn't need a 3rd party library to use what was supposed to be a major feature of the C++20 standard library, but right now you do. C++20 modules tend to be discussed as a replacement for headers, but when you start using them you find that they don't fully replace headers. They seem to be more useful for joining together code at the library level, rather than at the file level. (And of course only your own new libraries because existing libraries probably don't support modules yet.) Within each library you'll probably still #include headers. I think this is hinted at around slide 29/50 when it talks about "regular files". You could use module partitions but partitions and modules in general are just a ton of header style boilerplate with no real benefit over traditional includes.
Besides complexity, nobody is using it because it is 2024… and still it is not production ready. IMHO, I think that standard body should deprecate this, and try again. Don’t force all C++ community to support yet another mistake.
Useless perspective! Modules were introduced with C++20, and the standard library is modularized with C++23. It takes time to do this right. The modules proposals have been underway since 2012, don't kid yourself thinking this is easy or simple!
![АЛАУДИНОВ у Скабеевой: эти их ВСУ нас НЕ ДОГОНЯТ 😁 [Пародия]](http://i.ytimg.com/vi/an0anqU4WGQ/mqdefault.jpg)
Awesome! I've been looking for a good first talk on modules and in particular what I can do right now. The standard is very nice, but it seems a lot of module features haven't been implemented yet, which makes it quite annoying when I watch a lot of talks, they don't take that into account.
The best talk on modules thus far at CppCon
A small error on the slides: The CMake FILE_SET for modules sources is called CXX_MODULES, not MODULES.
Also, on slide #20 about interface partitions, the names of the module in the primary module interface and the partitions need to be consistent (either all 'm' or all 'mice', but not a mixture of the two).
Great talk, really helpful. Thank you!
Only C++ can take a concept this simple and make it hard
Contrary to pop opinion the header system is extremely good and won't be replaced any time soon.
Does it mean only C++ has real world use then? Since that's one of properties of reality, it makes simple concepts hard by virtue of nuance.
What is so hard about it?
@@indiesigi7807 I want to keep headers too, but make the classes open so i can extend them in private source files. That would be better and simpler.
@@iliasalaur They didn't try to work against the root of all this problems. Single translation units. A 1970s concept that is so wrong. We could have so much nice things if we could get of command line compilers and obj files, instead go with a server that get feed c++ source files and spits out executables. Thats the solution for the speed problem. The better abstraction could be solved by allowing open classes. Objective-C++ is doing it very well but only for the Objective-C.object model.
this reminds me of a helmet that i had that had a hammer attached to it. So everytime i want to nail something to the wall, i would wear that helmet and swing my head around to hit the nail.
but sometimes i miss and i hit my head against the wall instead. So to solve that problem, i added some padding to my forehead.
now everything works like a charm.
Another fellow jonathan blow watcher
Great talk, the include guard trick is genius!
Happy to have learnt through this talk how to export templates. I was putting the export on the function "part" and couldn't figure out why it wasn't working.
At this time (version 17.8.6) Visual Studio can with no problem have modules that wrap header files that include the C standard library. So, no problem if you write a module that uses a C library. That's already a big deal.
It won't work if you include a header that includes the C++ standard library. So if you try to wrap a C++ library that won't work because the library will include stuff from the C++ standard library and you will get name clashes.
So, the solution is to have an immediate wrapper module that just includes all standard library headers that are used by the wrapped library in the bit between module; and export module x;. and then exports the library. In most cases that will probably approach most of the C++ standard library. At least it's a trick that works (I verified with a minimal example). Hopefully this issue will be resolved and the trick will no longer be needed soon.
Has anyone figured out if intellisense work now with vscode + cmake + ninja? Still getting module not found errors
Thanks for the talk! So far the best source of explanation for modules.
Great talk!
Aside of CMake (as of 3.28) modules support by toolchains is very lacking. Neither Apple's clang 15.0 nor gcc 13.2 provide a dependency graph for CMake. clang 17.0 works somewhat with CMake (i.e. it configures and builts everything), but then VS Code can't handle dependencies and code completion, neither with the C/C++ plugin nor the clangd plugin. So for the time being it seems we have to wait for the tools to adopt still. "Getting started today"? No way.
It looks so much complex than the other languages module systems...
Only if you compare it with single vendor programming languages - rust, swift,... - that mandate (and provide) the build system. For those of us in embedded and system programming world we can't rely on those languages. We need C/C++ because it integrates with our systems, not finding a way to get those single vendors to care enough to support our system.
Complexity is the price we pay for flexibility, but in return we can ship product.
@@GregWhiteley you don't have to use cargo with rust
c++ has to be complex i guess
@@_ironrose Unfortunately yes. But we must remember that C++ is the only language out there that does not force programmers to write their software in any specific way. All C++ does is give us a set of tools and some loose guidelines. Rust assumes programmers can't be trusted and so places as many restrictions as possible.
C++ is getting better, sure, but due to legacy reasons it has a lot of "catching up" to do. Modules make C++ almost infinitely better.
Welcome to C++.
I don't like the fact imports are dumped into the current namespace. Perhaps if it was a bit more python-y in the way of : import B; B.my_import_func(); in lieu of a using declaration would provide a much cleaner namespace .
Namespaces help a little
in foo.cpp:
export module foo;
namespace foo { export void fn(){} }
in main.cpp
import foo;
int main() { foo::fn() }
This interface only requires that all your modules have a namespace that is the same as the name it uses when calling export.
In my_module_p{1,2}.cpp, you have "export module m:something;"... what is m? I don't see you declaring a module called m. Should it be mice instead?
yep, should be `mice`, not `m`. It's a compile err with `m` otherwise
Is 17:53 correct? My compiler thinks that the implementaiton module is trying to import itself. Oh wait, the code is correct but the compilation order is crucial, as was not mentioned. 21:29 should the "m:" twice be "mice:"?
Yes, the 'm:' on slide 20 was a typo and should be 'mice:'. Thanks for catching that!
// File: my_module.p1.cpp
export module mice:pinky;
export void narf() {};
// File: my_module.p2.cpp
export module mice:the_brain;
export void take_over_the_world() {};
struct SecretMasterPlan {};
.
.
I'm using visual studio and start to learn modules. The thing is there is bad tutorial on the internet. I import std module to other module that is in project which compile to static library (.lib). In that project I'm only using print function from cpp23. The lib file is about 4mb of size when using imported std. If this is normal? All library contining cpp standard library is linked to my library? Second, if I will link my library with other project that make executable file (.exe) and in that project I'm using cpp standard library (import std) ofcourse I' have to use std.ifc interface again but do I have link c++ standard library (.lib) files again? This is very practical information..not only to show how "nice" is write "import std".
Great talk, thanks! Some concepts here, like "export import", "export using", and the ability to export a function returning a non-exported type, make me a bit worried for the future of C++. A lot of people already get confused with headers, and this is IMO adding a whole lot of complexity. That doesn't matter for people who know what they're doing, but this just makes it harder to convince large teams / companies to use modern C++.
Exporting from module partitions is not a standard. GCC and Clang do not support it, and Clang developers have even said that it might never be supported! I would add a BIG NOTE at slide 20.
Shouldn’t CMake treat modules as libraries, or at least be able to do so? (Maybe it can and I missed it?)
Why would this be a good idea? A module is simply a translation unit. I think the approach of linking several module interface units together into a library is a much better solution. After all, a library may be formed from just a single TU.
Hmm you must be from the future.. I cannot find a visual studio release later than 17.8.3
Sorry for being imprecise there. The 19.34 is the C++ toolchain version, the number you get when running cl.exe, not the version number of the Visual Studio IDE that you get in the About... window in Visual Studio.
@@ComicSansMS thanks for clarifying that.
So .bmi files behave like small static libraries?
To me it sounds like the same thing as headers, but in binary format, for the compiler, so it's faster to parse and use.
No, like small per-compiled headers
It's too complicated. As a long term C++ dev, I really was hoping that C++ modules would ease my life and the one of my team. It's 2024 and I don't see the benefits of it so much: too verbose, error prone.. it's depressing because we had to set a new modern language in our stack because of my failure to predict what modules would end up like. My fault, but it kills me.
It will ease your life. At least I think so. Stick to module interface units for declarations and documentation, and module implementation units for definitions. You never need to worry about inclusion hell again. I would say that's a big win.
Will C++ 2025 reinvent the concept of .def files fir export definitions 😂😂😂
Modules were such a wasted opportunity to make something good, ended up ugly and overly verbose with so many rules to remember. Nobody will use, like coroutines.
Coroutines are already usable, although there are more libraries needed in the ecosystem. Asio already makes good use of them for async networking. Writing your own coroutine type is much harder, but most people don't need to do that.
Coroutines is a very different story, because there is a very small number of scenarios, where they could be handy.
Modules are exactly the opposite. This is the piece of standard, that must be used everywhere. I hope that in 2-3 years more compilers will add support for them, because you know, headers - suck
Coroutines are hard to implement, but easy to use. They are not meant to be implemented by everyone, only library implementers will need to do that, and then millions of C++ developers will be able to use them without knowing the implementation details.
@@iliasalaur I love headers. I love them much more then all the languages that mix the implementation with the declarations.The problem is not hte header but the single translation unit compilation speed (and some better implementation hidding). All of it could have been solved much better without this module system they came up with.
Coroutines have myriad possible uses. I have used coroutines in Unity for a variety of uses. Anywhere you have async code you can use coroutines and they have a simple intuitive syntax there. You shouldn't need a 3rd party library to use what was supposed to be a major feature of the C++20 standard library, but right now you do.
C++20 modules tend to be discussed as a replacement for headers, but when you start using them you find that they don't fully replace headers. They seem to be more useful for joining together code at the library level, rather than at the file level. (And of course only your own new libraries because existing libraries probably don't support modules yet.) Within each library you'll probably still #include headers. I think this is hinted at around slide 29/50 when it talks about "regular files". You could use module partitions but partitions and modules in general are just a ton of header style boilerplate with no real benefit over traditional includes.
3 years and still not properly usable. Good language 👍
Gonna stick with C
Why on earth would you stick with C? That language is close to useless for practical purposes.
@@007LvB ig the whole open source stack is useless TIL lmao
these absolutist takes are always the worst
Besides complexity, nobody is using it because it is 2024… and still it is not production ready.
IMHO, I think that standard body should deprecate this, and try again. Don’t force all C++ community to support yet another mistake.
Useless perspective! Modules were introduced with C++20, and the standard library is modularized with C++23. It takes time to do this right. The modules proposals have been underway since 2012, don't kid yourself thinking this is easy or simple!
Valid point @@007LvB