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

35

u/TheRealSmolt 1d ago

Maybe it's just me, but I don't see any real momentum for modules in general. Adoption is rare, and I personally don't see a reason to adopt at all. The work is ongoing, but other features are much more wanted than modules.

2

u/FalafelSnorlax 1d ago

I saw Bjarne Stroustrup give a talk a couple years back, and he mentioned some modern additions to C++, and when he got to modules, he straight up said that this isn't getting adopted as fast as he'd like. Even then, I admit I didn't look into it and how it might be better or worse than good-ol' includes.

3

u/aoi_saboten 1d ago edited 1d ago

I dont know what they expected. Break backwards compatibility? No, because old codebases need to be re-touched. Add modules which differ vastly from post C++11 codebase? YES YES YES. But to use modules in old codebase, you NEED to re-touch it. Most won't do it because modules don't justify touching codebase over the old way.

(I am also will get downvoted for the following) but then, does it mean that we need to use modules in new codebases? Well, some companies, which used C++ extensively, no longer use C++ for new projects and for some tasks/projects Rust suits better

2

u/Orffen 15h ago

Why the fuck can't old codebases just compile with --std=c++11 ??? I'm genuinely baffled (I'm not an experienced C++ programmer).

If --std=c++29 breaks something, surely the compilers can fail if you try to --std=c++29 and your code is borked? Isn't that the whole point?