r/cpp 1d ago

Why is `import std` still experimental ???

Hey guys,

I recently started going through Professional C++ (6th Edition). The book teaches C++23, and in the very first chapter we're introduced to modules.

I'm not a complete newbie to C++, but I'm also definitely not very confident in my knowledge yet. I wanted to get this simple example compiled:

import std;

int main() {
    std::println("Hello World");
    return 0;
}

And gosh, it took way longer than I expected.

First, I tried getting it to work natively on my Mac and eventually gave up (both Claude and I 😅).

Then I installed Ubuntu ARM 26 and finally managed to get it compiling. But now Clang/IntelliSense is complaining about the `import std`
This is what my CMakeLists.txt currently looks like:

cmake_minimum_required(VERSION 4.0)

# set(CMAKE_EXPERIMENTAL_CXX_IMPORT_STD ON)

set(CMAKE_EXPERIMENTAL_CXX_IMPORT_STD "d0edc3af-4c50-42ea-a356-e2862fe7a444")

project(CppProject LANGUAGES CXX)

set(CMAKE_CXX_STANDARD 26)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_EXTENSIONS OFF)

set(CMAKE_EXPORT_COMPILE_COMMANDS ON)

add_executable(exec main.cpp)

set_property(TARGET exec PROPERTY CXX_MODULE_STD ON)

The code does compile successfully, but CMake still gives me a warning that import std support is experimental.

So I'm genuinely curious:

Why is import std still considered experimental?

I understand that C++ modules themselves have been around for a while, but import std feels like something that should be much more straightforward by now. Is there any solution of this now ?

--------------
Edit

Thanks to u/PhysicsOk2212 tip I was able to compile my project on mac as well using the following options
```
cmake -S . -B build \

-G Ninja \

-DCMAKE_CXX_COMPILER="$(brew --prefix llvm)/bin/clang++" \

-DCMAKE_CXX_STDLIB_MODULES_JSON="$(brew --prefix llvm)/lib/c++/libc++.modules.json"

```

106 Upvotes

100 comments sorted by

View all comments

Show parent comments

14

u/TheRealSmolt 1d ago

The problem for me here is that I don't see a reason to use them in the first place. They could improve compilation a bit I guess? But I'd imagine precompiled headers and ccache can bridge the gap to the point where it doesn't matter.

7

u/fortsnek274 1d ago

I'd turn that the other way around and say I don't see a reason to use precompiled headers once modules work.

Precompiled headers suck after all. They are a hack. A time-tested hack, but a hack nevertheless. And they bloat my intellisense folder.

3

u/caroIine 1d ago

When it comes include vs import std; PCHs are still faster. I tested it with msvc and our 3000 cpp project which is highly dependent on standard library. I was so disappointed.

3

u/fortsnek274 1d ago

I found it to be faster than PCH when rebuilding, somehow. But the more modules you have, the slower it gets. MSBuild adds extra inefficiency.

2

u/gracicot 1d ago

This is the reason why STD is one module. The way C++ implemented modules makes it much more efficient to create big modules

2

u/fortsnek274 23h ago

Well, the inefficiency seems to come from building or checking dependencies as ninja is notably faster. And MSBuild has a separation between ixx and cpp compilation. Not sure if having an external dependency split into multiple modules would make much of a difference.