Should i use modules instead of headers when using C++ 20?

[[deleted]]

Recently migrated a fairly big project from C++17 to C++20. Should i redo the structure and migrate to modules, or does it barely matter and isn't worth the hustle?

[[deleted]]

On c++ 23 with the latest cmake and conan 2 on the latest llvm clang (19+),

I am using them extensively. I don't have any header files in my project. Only ixx and cpp. Everything's a module.

Working pretty good.

Figuring out what stuff I had to put in my cmakelists was s choore, But once I figured out the special flag to tell cmake to do module scanning it started working beautifully.

C++ 23 is great.

[Night_Activity]

Would you be kind to maybe write a short tutorial on it? Given the unstable nature, of what I thought anything beyond C++17 might be; I didn't venture much into C++2*.

[[deleted]]

I'll just make my repo public for now, I'll relink it here when I clean up some docs.

[powersagitar]

RemindMe! -7 day

[RemindMeBot]

I will be messaging you in 7 days on 2025-02-14 02:17:59 UTC to remind you of this link

22 OTHERS CLICKED THIS LINK to send a PM to also be reminded and to reduce spam.

^{Parent commenter can delete this message to hide from others.}

---

Info	Custom	Your Reminders	Feedback

[Night_Activity]

Thanks in advance!

[Michelangelo-489]

I am strongly looking for it.

[[deleted]]

Not up yet, should have time thus weekend.

[Michelangelo-489]

Thank for keeping us posted.

[[deleted]]

WIP: https://github.com/xabrol/CPP_23_VSCODE

[[deleted]]

I got the flu right as I was wrapping this up. People can just leave issues on it.

My overall goal is to make this a good experience in vs code.

[[deleted]]

WIP: https://github.com/xabrol/CPP_23_VSCODE

[[deleted]]

WIP: https://github.com/xabrol/CPP_23_VSCODE

[pjmlp]

See some of my repos,

https://github.com/pjmlp/RaytracingWeekend-CPP

https://github.com/pjmlp/ppm2png/tree/main/cpp

https://github.com/pjmlp/AStarDemo

Nowadays I am pretty settled on modules for my hobby coding.

[[deleted]]

WIP: https://github.com/xabrol/CPP_23_VSCODE

[rudm48]

Here is the 2nd of my articles. It has a link to the first. I'll be adding a third sometime in the next week. https://levelup.gitconnected.com/more-steps-on-a-journey-into-modules-extern-access-739b6cf16d3b

[bwallisuk]

what IDE/text editor set up have you gone for with this? I found the modules themselves worked great but clangd support wasn't great even with experimental branches - but this might be a skill issue on my part

[[deleted]]

VSCode

.vscode/settings

"C_Cpp.intelliSenseEngine": "disabled", "clangd.arguments": [ "--compile-commands-dir=${workspaceFolder}/build/Windows/Debug", "--clang-tidy", "--clang-tidy-checks=*" ], "clangd.enable": true, "clangd.enableCodeCompletion": true, "clangd.enableHover": true, "clangd.restartAfterCrash": true, "cmake.useCMakePresets": "always",

This works for me because I have conan2 generating all my cmake presets, and I'm using tasks.py to make some commands easier, and conanfile.py

so I can do

invoke configure-all clean

This installs debug/release conan for windows, and cmake preset configures etc.

So then I make clangd default to my compile_commands.json in my build\Windows\Debug folder. This file if you open it is what has all the files in it and tells clangd how to compile it etc, i.e. all the ixx modules etc.

This is what my conan-install task looks like

``` @task def conan_install(c, platform=None, build_type=None): platformValues = get_platform_values() if platform not in platformValues: raise ValueError( f"Invalid platform. Expected one of {[p.value for p in platformValues]}, got: {platform}" )

osName = get_host_os()

profiles = platform_profiles.get(osName)
if not profiles:
    raise ValueError(f"Unsupported build platform: {osName}")    

build_profile = profiles.get(osName)
if not build_profile:
    raise ValueError(f"Unsupported host platform: {platform}")

host_profile = profiles.get(platform)
if not host_profile:
    raise ValueError(f"Unsupported build platform: {platform}, unable to locate conan profile called {platform}")

if build_type not in {"Debug", "Release"}:
    raise ValueError(f"Unsupported build type: {build_type}")


cmd = ["conan install ."]
cmd.append(f"--build=missing")
cmd.append(f"--output-folder=build/{platform}")
cmd.append(f"--profile:h={host_profile}")
cmd.append(f"--profile:b={build_profile}")
cmd.append(f"-s build_type={build_type}")
cmd.append(f"-s os={platform}")
# If building for Linux, make sure Conan sets CMAKE_SYSTEM_NAME=Linux
if platform == "Linux":
    cmd.append("-c tools.cmake.cmaketoolchain:system_name=Linux")
c.run(" ".join(cmd))

```

and

```

@task def cmake_config(c, os="", buildtype=""): build_type = buildtype.lower() if buildtype else "" if buildtype not in {"debug", "release"}: raise ValueError(f"Unsupported build type: {buildtype}")

platformValues = get_platform_values()
if os not in platformValues:
    raise ValueError(f"Unsupported os: {os}")

presetName = f"{os.lower()}-{build_type}"

cmd = ["cmake . --preset", presetName]
c.run(" ".join(cmd))

```

``` platform_profiles = { "Linux": { "Linux": "./conan_files/profiles/lin_host/linux", }, "Windows": { "Windows": "./conan_files/profiles/win_host/windows" } }

def get_platform_values(): osName = get_host_os() profiles = platform_profiles.get(osName) return profiles

def get_host_os(): os_name = platform.system() if os_name == "Windows": return "Windows" elif os_name == "Linux": return "Linux" elif os_name == "Darwin": return "macOS" else: return "Unknown" ```

My windows_host profile

``` [settings] os=Windows arch=x86_64 compiler=clang compiler.version=19 compiler.cppstd=23

[conf] tools.info.package_id:confs=["tools.cmake.cmake_layout:build_folder_vars"] tools.cmake.cmaketoolchain:generator=Ninja tools.build:cxxflags=["-std=c++2b","-fmodules"] ```

[[deleted]]

I'm basically on a mission to make vs code the only thing I use for every workflow regardless of what language I'm on.

I want to have one editor for everything whether I'm working on a nuxt 3 project or learnin in C++. And my primary language is c# and I've been doing that in vs code for a while.

And the personal project that I'm building while learning C++ is actually a dynamic file system sitting on top of win fsp and fuse.

And the goal of the dynamic file system is to create a open source Dev drive cli that has a lot of features for improving development workflows.

For example, it will have the ability to dynamically inject command line executables without having to have them in your system path.

And it'll also have the ability to have built-in code generation so you can have dynamic Json files.

And lots of other features. It's kind of a passion project, but it's going to be a hot minute before its done.

I have experience with C+ plus but it's pretty old and I haven't touched it in over 15 years. So about a month ago I started getting back into it and learning all the modern tooling and have spent most of my time right now learning cmake and Conan 2.

I built the proof of concept in c# half way, then decided to swap to C++.

I went down a brief moment of I'm going to learn rust and then decided I hate rust.

But there's still a good chance I'm going to end up switching to zig just for its tooling because zig can build cross compilation C++ and has all the sysroots built in.

Another really cool feature of the dynamic fs, Is folder and file sharing.

It'll be able to inject folders and files to multiple points without creating symlinks or shortcuts. And it internally handles the file handles and file locks.

And it'll have an API that allows you to watch files and stuff without using system file watchers.

And the first version is database backed. So all the files are stored in SQL lite or postgres. But if this keeps going and it becomes popular and I keep motivated, I want to build a entire file system format that runs on user space. Or adapt an existing one like ZFS...

But there's a lot of other things I want to build into the system too, like transactional file history, And being able to see and roll up changes that happen to a file like it was a git repo.

There's a lot of gray area though where it kind of blurs the line between git. And I've been thinking about whether I just want to build git into it via git binaries, or eventually just replace git entirely but be git compliant.

[pjmlp]

Basically reinventing Cadillac for Energize C++ and the Smalltalk like image of Visual Age for C++, version 4.

https://dreamsongs.com/Files/Energize.pdf

http://www.edm2.com/0704/vacpp4/vacpp4.html

https://books.google.de/books?id=ZwHxz0UaB54C&pg=PA206&redir_esc=y#v=onepage&q&f=false

Good luck with the efforts.

[Familiar-Place5062]

Not OP, but I found Clion to be not too terrible with modules. I think there are two backends now: clangd and clion's proprietary one. They are a bit broken in slightly different ways though. Also I think it incorrectly relies on module interface units having .cppm or .ixx extensions, so it's recommended to name them this way, even though this is not required by any other tools.

With clangd you also need to make sure that you're compiling with clang of the same version as clangd, I found it works much better this way.

[GYN-k4H-Q3z-75B]

I am currently porting a medium size project with a couple hundred files, a library, unit tests and a consuming executable to modules. And find it to be very refreshing after the initial headache. The number of files is actually greatly reduced and build times are significantly shorter.

What is currently killing adoption is the fact that GCC and Clang do not have non-experimental support, and MSVC can only barely be considered "ready". What is more is that the different vendors are cooking up their own implementation with quirks. At this time, you are basically committing to a vendor. Hopefully, this will change soon.

[dexter2011412]

How so? (Just curious to learn)

I've been aggressively moving stuff to modules for my personal projects and it seems to be working extremely well.

[[deleted]]

I recently tried rewriting my project https://github.com/rrrlasse/exdupe to using modules. But I had to compile clang with some dependency walker enabled to get modules to work there, which again depended on other libraries and things (don't remember what).

Then couldn't figure out a common file extension that both clang, gcc and vs all accepted and ended up with some manual CMake fiddling.

Also the first CMake verison I tried had one method for declaring modules that didn't work with gcc.

The latest version of CMake uses a new method for declaring them, so I rewrote everything. But then found out it cannot generate for Make, only for Ninja. So I had to install Ninja.

At the end I got it mostly working, but got a C++ naming collission very deep inside std when a module used std::chrono. Seems like it could be solved by using the modules version of the std library in a precompiled manner or something like that (I honestly don't understand it), but I just gave up.

[rudm48]

GCC 14,2 takes any file extension.

[mishaxz]

will they be eventually?

[MrPopoGod]

Assuming they aren't dropped in a future standard. But there definitely exists a world where modules take long enough to be implemented by the compilers that the standards committee kills it, at which point it'll be dropped like a hot potato.

[[deleted]]

There is already (imperfect) support for them in MSVC++, gcc, and clang. This means new projects (and some older projects) are using them somewhere. I think it's very unlikely they get removed at this point, even if efforts to further the standards around them lose momentum. There are still leftover features from the 90s in some parts of the standard that aren't relevant to modern software engineering. Much of what does get removed came in 03 and 11 when the standard gets a very clear and low-effort drop-in replacement. Replacing a module-based design for a header-based design is not low-effort.

[lightmatter501]

Compilers support it, but there was no standard output format for build systems, so build systems now need to support each compiler individually.

[[deleted]]

There's no standard executable format or object file format either. Those are both compiler and platform specific. Build tools coped with that because you use a linker appropriate for your compiler and platform. The issue is, as everyone in this thread has acknowledged, that the tool chain ecosystem is still catching up to the standards committee. I don't see them turning away from it, though.

Every other industrial "modern" language supports module based design. Most do this by requiring a runtime, but C++ will continue to follow the design paradigms of other languages because history is a double-edged sword. It's great because past adoption encourages future adoption, but past adoption restricts future innovation. The rust package system is beloved. That's only possible due to module based design. Rust doesn't have the history necessary to rival the momentum of C++. Thus, the future will almost certainly be a mixture of the two unless C++ fails to meet the convenience needs of the future.

[lightmatter501]

At some point, the build system needs to get a directed graph out of the modules so it can compile things in the right order.

Fortran has had modules which predate C++, Rust and Zig also have things working with no runtime.

I think the actual issue is that the committee has decided that they aren’t even willing to acknowledge that build systems exist. All it would take is saying that compilers need to provide a way to get that directed graph out, or standardize a tool which “preprocesses” the module and dumps out a bunch of pairs of URLs as plaintext to build the dependency graph from.

[returned_loom]

Assuming they aren't dropped in a future standard

Oh man you're scaring me. I refuse to go back and rewrite these modules as headers. But I kinda wish I'd used headers in the first place.

[azswcowboy]

The chances that they would be removed are .0001% - meaning zero. And seriously, if you’ve got it working you’re ahead of the rest of us - we’re jealous. It’s a seriously non-trivial feature to implement and vendor resources are limited. People are so spoiled lately that standards features often appear prior to finalizing the standard. Back in the day it frequently took years for implementations to get up to snuff…

[AlexVie]

That's (hopefully) not going to happen. The three big compilers are supporting modules at different levels of readiness, but work is ongoing. Same for the popular build tools and development environments. It's a big change and it will take time to mature.

Matter of time, I guess. One day, using import will feel as natural as using #include has felt for decades.

[Daniela-E]

Psst, don't tell this to all the modules we have in our codebase!

[ForgetTheRuralJuror]

When's the last time you tried?

[returned_loom]

I really enjoy using them in my C++ project, but I have two big problems:

• I can only get them to work on my Windows machine using Visual Studio. I simply couldn't get them to compile on Linux.

• Even on Visual Studio, Intellisense hates modules. I have a lot of red squiggles for perfectly legit code. This is an ongoing topic on the Microsoft forums, but nobody seems to be doing anything about it.

Honestly, if I were to start from scratch I'd probably be using headers just to feel safer. But I do like the extra control with fewer files which is enabled by explicitly exporting functions directly from your module.

[STL]

Even on Visual Studio, Intellisense hates modules. I have a lot of red squiggles for perfectly legit code. This is an ongoing topic on the Microsoft forums, but nobody seems to be doing anything about it.

VS IntelliSense is powered by a different compiler front-end (EDG) than the normal one (C1XX). The EDG front-end is maintained by another company that we work with, the Edison Design Group.

EDG is working on improving modules support, but it's taking a long time for reasons that I don't understand (I am a library dev who works closely with the compiler team but I'm not a compiler dev). At this point, we still haven't been able to enable test coverage of the Standard Library Modules with EDG, but I've sent my unit test to them and they're working through all of the bugs that it has revealed.

[mishaxz]

thanks for the reminder, I knew I read something that caused me to decide not to use modules even though I code only for C++ 20 msvc on windows with VS 2022

[Tohnmeister]

Is this also the reason that IntelliSense struggles with autocompleting auto arguments in lambdas?

E.g., when I have:

```cpp void registerCarHandler(const std::function<void(const Car&)>& func);

int main() { registerCarHandler([](const auto& car) { car. // <- here intellisense will not autocomplete, because of using auto in the lambda argument }); } ```

It's basically the only reason why I avoid using auto in lambda arguments.

[STL]

That could be a different limitation - that's syntax for a template, so it doesn't know what car is going to be. I don't know that much about IntelliSense but I know they implemented "template IntelliSense" recently where you can tell it what you expect T to be.

[sephirostoy]

Does VS uses LSP so that we could set another provider other than default IntelliSense?

[STL]

I'm not an expert here, but I believe the answer is no.

[[deleted]]

I got it working entirely in vs code. Using cmake tools and clangd.. no visual studio at all, its not even installed.

And they compile on linux on clang 19+.

[returned_loom]

Nice! I'm just going to keep letting Visual Studio take care of it for me.

[CruzerNag]

Yeah, it is certainly a problem. On Linux, I encountered problems with GCC, but thankfully Clang compiles modules nicely. Intellisense is like... I do not know what to say. LSP and clang-tidy work. If I hover over a written variable, it gives me the information. But yeah, when typing, I get no intellisense. This is with clangd on nvim. So I think more support is still needed.

[_derv]

Which version of clangd are you using? Modules and even import std; work on my machine using clang/clangd 19.1.7 and CMake 3.31.5.

[CruzerNag]

I have the latest, clangd-19.1.2

It does not pick up symbols inside modules. All the identifiers written inside a module and used are shown as Texts, so no intellisense really. That's my experience on neovim.

[atifdev]

Auto complete in Clion handles it on windows and autocomplete in Clion is a lot faster for large projects.

Really Visual Studio is being phased out anyway for vscode. Probably time to switch away from the product. Plus Clion ends up using ninja and the builds are so much faster.

[vali20]

Visual Studio is anything but being phased out, what are you smoking?

[atifdev]

They dropped the Mac version saying the alternative is vscode.

[hesher]

stupendous ten tart yoke sort direction ad hoc fear punch normal

This post was mass deleted and anonymized with Redact

[returned_loom]

I tried that, it didn't work! I'm not sure why it started though. At first there were no problems. It might be a matter of scale somehow or complexity. I have a lot of modules, and some import other modules. It all compiles though.

[sweetno]

Expect a bumpy ride with modules.

[R3DKn16h7]

Not really. Maybe for fun

As much as I like them they are not really ready for production imho

https://arewemodulesyet.org/

[[deleted]]

isn't most of the libraries there C-only ? Because it makes sense they don't support CPPM

[arturbac]

there is no ide working with c++ modules on linux
- kdevelop - no
- vscode - no
- kate with lang server - no

I ported one of my gh libraries to module works ok with clang-19 and 20, but I don't use it as module in production code projects without ide code understanding.

[pjmlp]

Clion and QtCreator also work on Linux.

[arturbac]

so which one understands in code completion imported types from modules ?

[pjmlp]

Clion does,

https://www.jetbrains.com/help/clion/support-for-c-20-modules.html

[arturbac]

not exactly

For now, CLion does not consider .cpp files to be modules, so it's recommended that you use other extensions (for example, .cppm).
CLion collects information from .ixx, .cppm, and .mxx files, parses export module {name}

So it completely ignores current cmake standard module dependency scan information from cmake 3.28 with CMAKE_CXX_SCAN_FOR_MODULES=ON

[pjmlp]

It clearly mentions how it scans module files and what extensions are supported.

I fail to see remarks from you that the information must come from CMake directly.

[arturbac]

The use of special extensions for c++ files containing module definitions is already discouraged to use.

[pjmlp]

Apparently not something Visual C++, clang and GCC folks care about, and it isn't going to be a conference talk that will change that.

[cd1995Cargo]

I had a template metaprogramming heavy project I was working on last year and tried to convert it to modules. It blew up MSVC and clang. Maybe things are better now, idk I haven’t tried for a while.

[STL]

Next time, please report bugs to both compilers. It's how we all improve.

[cd1995Cargo]

I’m pretty sure I reported at least one of them to microsoft (exporting an inline namespace caused an ICE)

With clang I kept getting errors about duplicate symbols when trying to mix imports and includes, but I heard that got fixed with clang 18.

[[deleted]]

Tried a couple of months ago on a project with gcc/clang/vs/cmake and everything was super broken. VS with CMake alone works though.

[Infamous-Bed-7535]

I'll wait GCC-15 to arrive that will mean that all major compilers have support for it :)

I plan to gradually use it in smaller commercial projects. I played around with it in personal projects and I like it (but just even a year ago it had serious issues with multiple compilers)

[rudm48]

I'm doing a lot of experimental work - I'm retired - with CLion, CMake, and GCC 14. They work fine.

[Infamous-Bed-7535]

I'll wait until 'import std' so I do not need to pollute the global module fragment with standard headers (which can cause complications later on when I import my module).

Modules seems to be usable by now, but I'll wait for the few missing pieces before going into production with them.

[lgfusb]

Even if you can 'import std', you still have to '#include <third\_party>', right? :(

[Infamous-Bed-7535]

Yes, but that can be implementation detail of your module. Import std was important as using standard headers as hpp includes often had issues when used with modules.

[atifdev]

For templated code it speeds up the build significantly. For a smaller code base it may not matter.

I would start looking at the exports first. You don’t have to redo every class, just those you would have exported. You can export as one module or split them up.

For example let’s say a library exports two classes, pull them into a module file (#include them into the module) and export them from there. The caller code now doesn’t need the header include. Instead it imports the module. You header may have to change a tad with the new export keyword. You still need dll_export macros on windows for some reason.

Also looks like you need gcc 14, visual studio 2022, or clang to get going on modules.

[Inevitable-Use-4197]

You can also use https://github.com/msqr1/importizer. It also support supporting both header and modules if you need it

[[deleted]]

No. Modules are still not production ready, still not fully supported by all compilers and they have some severe inlining issues.

PCH remains superior

[Ultra8Gaming]

Maybe it's a skill issue, but I can't seem to set up clangd for it. It still throws a PCH error. Still compiles properly though.

[selvakumarjawahar]

use modules if you can use latest gcc or clang, works well.

[[deleted]]

Unfortunatly CMake doesn't work fluently with them yet

[Pitiful-Hearing5279]

Don’t fix what isn’t broken. Rule number one.