Incomplete list of standard lib C++ headers in non-module case

[fedapo]

File cpp2util.h has the list of headers of the C++ standard library to implement the Cpp2 feature of an always-on standard library. This list is repeated in a few branches of a pre-processor if-else statement to allow pre and post C++23 build scenarios.

The non-module, pre-C++23 list is incomplete.

I suggest to make this list as complete as the other case and, possibly, sort the headers alphabetically of quicker checking whether an item is missing.
I'm aware that this list is temporary and the steady-state solution is a simple import std;, still, it'd be nice to be able to run some tests with cppfront with today's compilers for a larger class of cases.

[gregmarr]

Based on the commit you sent, the section that you're looking at is commented like this:

//  Otherwise, we're not in -pure-cpp2 and so just #include
//  what we need in this header to make this self-contained

That CPP2_USE_MODULES define is a bit confusing. It could really be CPP2_STRICT or CPP2_PURE. It means that the user hasn't said that the file is pure cpp2.

@hsutter Is it expected that you need the pure-cpp2 flag to get the automatic import std; behavior?

[hsutter]

@hsutter Is it expected that you need the pure-cpp2 flag to get the automatic import std; behavior?

Yes, that's right. Right now it's

            if (flag_cpp2_only) {
                printer.print_extra( "#define CPP2_USE_MODULES         Yes\n" );
            }

[gregmarr]

@hsutter Is it expected that you need the pure-cpp2 flag to get the automatic import std; behavior?

Yes, that's right.

So then it seems that the current behavior is expected, and if you aren't using the flag, then you still need to include these things manually to use them.

[hsutter]

Ah, I see the confusion.

Yes, CPP_MODULES has two effects now: It uses modules, and (because module import is fast) it also does import std;. But for portability today since most compilers don't support modules yet, I put the "include everything" fallback to simulate import std; availability.

What I'm now hearing is that having the whole standard library always available is so useful that including all standard headers should happen whether using headers or modules, and it doesn't seem to be affecting compile times significantly. Correct?

[JohelEGP]

Here are the wall clock times (best of 4)
when compiling main: () = {} on my system.

• GNU = GCC + Libstdc++
• LLVM = Clang + Libc++

Build	No flags	-pure-cpp2
GNU 13 (C++20)	0m1.179s	0m3.021s
GNU 13 (C++23)	0m1.271s	0m3.259s
LLVM 16 (C++20)	0m1.974s	0m3.141s
LLVM 16 (C++2b)	0m1.881s	0m3.205s

[gregmarr]

That's adding 1.2s to 2s per file, that seems like a lot comparatively speaking.

[leejy12]

Here are my results (average of 10 runs) comparing No flags, -pure-cpp2 (all includes), and -pure-cpp2 with std module.
I'm using MSVC, and compiled the same code as @JohelEGP

build	time (s)
No flags	1.143s
-pure-cpp2	2.279s
-pure-cpp2 with import std;	0.227s

Modules are fast!

[JohelEGP]

This is not an equivalent comparison.
Here I use https://github.com/JohelEGP/cppfront/tree/cpp_modules
(with the Cppfront flag -module-cpp2util,
so I can import cpp2.util; which does export import std;).

Here are the wall clock times (best of 4)
when compiling main: () = {} on my system.

• GNU = GCC + Libstdc++
• LLVM = Clang + Libc++

Build	No flags	-pure-cpp2	-module-cpp2util
LLVM 16 (C++20)	0m1.974s	0m3.141s
LLVM 16 (C++2b)	0m1.881s	0m3.205s
LLVM 18 (C++26), -O3, import cpp2.util;			0m0.033s

[hsutter]

@JohelEGP am I reading that last table correctly as saying that, compared to bringing in the entire standard library via #include:

• bringing in only the headers cpp2util needed, using #include, was 60% faster
• bringing in the entire standard library using LLVM 18's import std; implementation was 100x faster

?

[hsutter]

BTW it seems that means cpp2util.h should be updated to use modules on LLVM 18. I didn't realize they were really ready to be used to import the standard library, if they are that's great news!

[JohelEGP]

BTW it seems that means cpp2util.h should be updated to use modules on LLVM 18. I didn't realize they were really ready to be used to import the standard library, if they are that's great news!

It's currently experimental and opt-in via CMake: https://libcxx.llvm.org/Modules.html#using-in-external-projects.

@JohelEGP am I reading that last table correctly as saying that, compared to bringing in the entire standard library via #include:

* bringing in only the headers cpp2util needed, using `#include`, was 60% faster

* bringing in the entire standard library using LLVM 18's `import std;` implementation was _100x faster_

?

That's right.

[JohelEGP]

• bringing in the entire standard library using LLVM 18's import std; implementation was 100x faster

An important clarification is that it imports a module cpp2.util based on the header "cpp2util.h".

[hsutter]

An important clarification is that it imports a module cpp2.util based on the header "cpp2util.h".

I don't understand... what is the difference between that and import std;? and what is cpp2.util (is that a module you wrote yourself)?

[JohelEGP]

Yes: https://github.com/JohelEGP/cppfront/blob/cpp_modules/source/cpp2util.cpp2.
Even if "cpp2util.h" looks lightweight,
importing a named module is still much faster than a "lightweight" header include.

[hsutter]

So that module-import data does import the entire standard library (because it does import std;) and it also additionally the things declared in cpp2util.h? So it's still a good measurement of how cheap it is to module-import the whole standard library?

[JohelEGP]

That's right.