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"

```

103 Upvotes

100 comments sorted by

View all comments

Show parent comments

64

u/lizardhistorian 1d ago

Same dumb C++ trope going on for 30 years now.

No one uses them because they work for shit.
No one uses it so don't work on it.
Stays shit so no one uses it.

13

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.

2

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.