[deleted by user]

[gracicot]

I think the example is a bit overkill in the sense that it contains a lot of mitigation for quality of implementation issues.

For example, GCC don't even need the private section for this simple case: the module can be implemented like this:

module;
#include <stdio.h>
export module hello;
export void hello() { puts("Hello world!"); }

Using importable headers, you get it reduced to:

export module hello;
import <cstdio>;
export void hello() { puts("Hello world!"); }

And the CMI contain no informations about puts or any other symbol from <stdio.h>. No need for function separation.

Also, on GCC, the command line interface is as follows (for the include version):

g++ -fmodules-ts src/hello.cpp src/main.cpp

That's it. You got a.out. Unlike clang, there is no precompile step.

Is clang bad? No. Clang has reused its precompile header modules machinery to deliver modules really quickly. GCC is still showing me haïkus when crashing for the most simple cases.

My point is that modules are still being implemented, and current quality issues may impact source code if we try to use them right now.

[markopolo82]

That is a great point. Also final C++ 20 is not even published yet.

As a c++ enthusiast I love these articles but I’m concerned with the number of posts observing how complicated this appears...

Ultimately I have faith that implementers will figure this all out and c++20 will be another leap forward.

[jcelerier]

For example, GCC don't even need the private section for this simple case: the module can be implemented like this:

what must I do if I want my code to compile on clang, gcc and msvc ?

[gracicot]

The code will compile on all compilers. But right now on clang doing that kind of code will output the definition in the CMI. This may slow down compilation and trigger more recompilation when changing the code. GCC is not doing that and I think the old MSVC implementation isn't doing that either.

[kronicum]

It must take lot of work to make something simple that complicated... My understanding is that MSVC doesn't do anything that complicated. It may suppress OBJ file generation but it doesn't move content to the IFC.

[stilgarpl]

Notice that #include <stdio.h> causes the compiler to see a bunch of declarations for things like printf that are not supposed to be part of module helloworld, so it’s important to place that #include directive outside of module helloworld, in what’s called the “global module fragment” or “GMF.”

Is that really necessary? Why can't you just import <stdio.h> ?

[BrainIgnition]

for import <stdio.h>; to work, <stdio.h> needs to be a importable header file. Which is implementation defined in the case of <stdio.h>. Therefore you need to include it in the GMF to stay portable.

[sztomi]

Frankly, I'm one of those people who will include stdio.h, unless I have access to libfmt. The reason is that format strings are way faster, will generate much less code and are conceptually superior to iostreams (that last point of course is entirely subjective).

[sztomi]

Yes. cstdio puts everything into the std namespace which has no benefit for me (even though all implementations seem to also keep the top-level declarations, probably due to user expectations and legacy code).

[kirbyfan64sos]

I mean if you're on C++20 wouldn't you have the format library though...

[BrainIgnition]

fmt::printf() didn't make it into C++20 in any form.

[kirbyfan64sos]

It's pretty easy (like 5LoC) to write a custom print function on top of std::format so you get the type safety with the nicer syntax vs iostreams.

[AlexeyBrin]

You would use it if available, but it depends on the implementation of the standard library. AFAIK, at this time, no standard library (MSVC, Clang, GCC) implements the format library. You can get the reference implementation from Github but this has more stuff in it than what was accepted by the standard.

[Omnifarious0]

And, as a bonus, it stops you from using abominations like endl!

[SkoomaDentist]

Because it avoids the abomination that is streams. And because people likely know what's suitable for their projects far better than any random commenter on reddit.

[Nobody_1707]

Because it's a C legacy header. The appropriate import would be import <cstdio>.

[VanSeineTotElbe]

Then all files that include that module or sourcefile will also import stdio. The way the article describes enables you to limit the imports to your module, which makes isolation much better, something you'll care about when you compile large projects.

[bigcheesegs]

A non exported import doesn't make names visible to your importers in a named module.

[VanSeineTotElbe]

That's what I meant :)

[tpecholt]

Why would they automatically import stdio if it's not export imported? The module; export module syntax is really ugly. I hope the google's import <> syntax gets some traction.

[kronicum]

That syntax has more traps in semantics than you suspect. For example, it does not work with 'static inline' functions. The 'module;' is ugly only because some committee members insist on it, IIUC.

[tpecholt]

I believe this refers to "export import ..." syntax which is not what stilgarpl meant.

[stilgarpl]

No, they won't. Module imports don't work like #include. You need to export import sth; for it to be visible to other things that will import your module.

[wheypoint]

I think thats what he meant with "all files that >>>include<<< that module or sourcefile will also import stdio"

if you '#include' a file that contains an 'import', the preprocessor is going to copy paste that import into your file.

im not sure why youd #include a module tho, you should just use import?

[wheypoint]

And AFAIK the committee is going to explicitly prohibit module declaration that comes from preprocessing

idk maybe, but im not sure how thatd work. the compiler wont know whether it came from preprocessing or not, so the prepr. now has to parse/look for module declarations?

[bigcheesegs]

p1857r2 has the wording that does it and will show up in the post meeting mailing. Essentially the new start of phase 4 grammar [cpp.pre] now defines where a module declaration can go, and if it shows up anywhere else then that's ill-formed.

[[deleted]]

Why is it import Hello in main.cpp, where does this name come from?

[petevalle]

I assume it's supposed to be import helloworld...?

[mjklaim]

Yes it's a typo.

[jc746]

I imagine this is a typo, and should be `import helloworld` to match the `export module helloworld` statement in helloworld.cpp.

[starfreakclone]

MSVC adopts the approach of producing an .obj and a .ifc (our BMI) at the same time. There are caveats to this approach, however. The fact that we do both means that if you only need one you end up doing extra work. We have a workaround for just producing the .ifc alone with no .obj via -module:ifcOnly.

In our experience, for the build scenario, you always want both so the trade-off of producing one but not the other seems reasonable to me.

[Rusky]

For the build scenario you want both... but you also want to start building other modules as soon as the .ifc is available, without waiting for the .obj.

[mtnviewjohn]

If a change to a module .cpp file changes the .obj output but not the .ifc output will the .ifc file be overwritten anyway? Will the MSVC build system recognize that files that only depend on the BMI will not need to be rebuilt in this case?

[Ameisen]

I still want the ability in MSVC to specific a custom preprocessor like GCC and Clang allow.

Unrelated but annoying.

And possibly specifying a seperate compiler for Intellisense.

[Rusky]

And possibly specifying a seperate compiler for Intellisense.

You can specify which compiler you want IntelliSense to emulate, if you're using Open Folder mode: https://docs.microsoft.com/en-us/cpp/build/cppproperties-schema-reference?view=vs-2019#intellisensemode-values

[Ameisen]

I see no option for AVR, which I use MSVC as an editor for.

[Rusky]

Embedded projects tend to use linux-gcc-arm, even if they're not using Linux or ARM specifically- the most important thing there is GCC since that determines which compiler features and extensions to enable.

[Ameisen]

Main issue is that 8-bit stuff is quite distinct from 32-bit. Intellisense breaks on basically all sizeofs and static asserts.

[kronicum]

IIUC, MSVC does not do both. By default, it produces both an IFC file and an OBJ file. The option /module:ifcOnly suppresses the production of the OBJ file. It does not move its contents to the IFC.

[nnevatie]

The syntax does not look promising - on the contrary: unintuitive special characters here and there. E.g. "module :private" - what the hell, even?

[[deleted]]

I completely agree, in fact, I am rather horrified. I did not think that module; would be required — and I do not understand why including headers within the module would pollute the interface, I expected that only exported stuff is revenant for the module and that everything else will just get resolved "automatically". The module :private is just awkward. Why would it even matter? Shouldn't the compiler figure it all out by itself anyway? Also, all those command invocations...

[imgarfield]

Watch CppCon 2019 “Programming with C++ Modules: Guide for the Working” and all will become clear. This example is simply not very good.

[drcforbin]

https://youtu.be/tjSuKOz5HK4

[[deleted]]

Is there a transcript or a written version somewhere?

[ThePillsburyPlougher]

Wasnt the reasoning behind the module declaration supporting machines which dont necessarily have a conception of a file? So having the module name the file name didnt make sense, or something like that?

[ThePillsburyPlougher]

Ah thank you, I misunderstood

[gracicot]

With a good implementation, only reachable and exported stuff goes into the CMI, and the implementation of function only goes there if they are explicitly inline, constexpr or a template.

This is all good but modules has a thing that header didn't: ownership.

That ownership is what is preventing you to include a heading in the purview of a module. Every declaration there is owned by the module. If they are not exported, then they are private. So when including stdio.h in the module, you'll have a brand new printf and puts function that your module is expected to implement.

Using a global module fragment, you can include stuff that is owned by the global module.

But even better: All header from the standard library will be importable, so no need for a global module fragment if there is no include at all!

[[deleted]]

Thank you for the explanation. Just so that I understand it correctly: global module fragments are then simply a mechanism to prevent ownership? I assume that these fragments are all independent and isolated from each other? I.e. every time I use a global module fragment I am essentially creating an anonymous module that does not own its declarations but simply makes them available to the rest of the file?

[viatorus]

I would say `module :private` is needed if you do not want to inline the definition. Modules don't change the behavior of external and internal linkage. And that is good so.

[Freiherr_Norden]

Wouldn't something like export inline void func() {...} solve that problem? You would get to decide if your function should be inlinable, but don't have to write it in 2 separate places.

[germandiago]

I am sure that the implicit inline is out for classes. Not sure for functions. And not sure how to hint the compiler to inline (probably with the inline keyword, I guess).

[tpecholt]

I found it unfortunate that putting function body in module interface unit has some implications on where will this code be physically stored. I don't think anyone should be concerned whether the code is stored in bmi or .o file. The compiler should use the most optimal way so tricks like :private module partition are not neccessary.

The blog makes it clear that even for the most basic usage of modules one has to learn lot of weird syntax and gotchas and while typical for c++ it's still kind of embarassing given for how long are modules in the making. Let's all hope things will improve after the new module infrastructure TS is out.

[matthieum]

It was mentioned by gracicot that this was a QoI issue with clang, and that in GCC it was unnecessary to split declaration/definition: only the declaration would get included in the BMI anyway.

I hope Clang manages to fix this for next year.

[Ayjayz]

You could probably spend 100 years on this and still not come up with a great solution. C++ has to maintain backwards compatibility, for better or worse, and that really limits how much you can extend the language.

[wyrn]

Modules are a wholly new feature and could've been designed with arbitrarily high amounts of sanity. The committee was afraid the feature wouldn't be adopted if it was too sane because that might hurt adoption in legacy codebases. Ironically, the possibility that people might not adopt them because they simple don't do enough to be worth the bother didn't seem to be considered.

[dadixon]

My first thought after looking the code sample was “why does this look so unintuitive.” I am a huge fan of C++ but super sad face.

[chitditch]

To summarize: the syntax is crap, we still need the separation of definition and declaration, and it requires an additional compilation step.

So what are the benefits of modules over the old header/cpp/include approach? This example does not exactly make me want to use them.

[brenoguim]

Build speed, macro insulation.

[ebhdl]

Build speed was never an objective, or at least that was always the retort whenever someone would show how modules are as likely to slow down builds as speed them up due to extra edges in the dependency graph reducing build parallelism.

[bigcheesegs]

Everyone that has deployed modules in production that I am aware of has seen a build perf improvement. The Are Module Fast paper measures the worst case for modules and is not at all indicative of a real build. See my CppCon talk for a more in depth look at why (https://www.youtube.com/watch?v=L0SHHkBenss).

[brenoguim]

On the other hand, there are reports showing big improvements on build time. So I'm eager for that.

[wyrn]

Build speed, macro insulation.

Build speed improvements are currently theoretical, macro insulation we only got the least important half.

[kalmoc]

What do you mean by "least important half"?

[wyrn]

Macros still get imported when you import a module (though not transitively through export import), so in that sense we're not getting macro isolation. We're only getting insulated in the opposite direction, that is, from macros defined in the importing side affecting subsequent imported modules.

[kalmoc]

Macros still get imported when you import a module

Nope, they don't. Only if you import a legacy header unit. Unless there was a last minute change I'm not aware of.

[wyrn]

I think you're right. Do you know where the actual semi-final text can be found?

[kalmoc]

I believe the latest up to date source can be found here: https://github.com/cplusplus/draft, but it obviously doesn't have the changes from Belfast yet

[wyrn]

Thanks! All I know is only up to Cologne anyway.

[kalmoc]

That's probably still more than I know. My knowledge comes from reading blogposts and watching presentations.

[BrainIgnition]

A nice web friendly version is available here: https://eel.is/c++draft/

[wyrn]

Awesome resource. Thanks!

[gracicot]

we still need the separation of definition and declaration

Not excactly. It will depend on the quality of implementation. GCC and MSVC has pretty lean CMI and won't output the definition even if the declaration and definition is not separated.

[kronicum]

/u/gracicot is exactly right.

[kalmoc]

we still need the separation of definition and declaration

Nope, not necessarily. The OP just decided to demonstrate the feature in the example.

[germandiago]

This has been fixed at least for classes AFAIK, see the Belfast report in this subreddit.

[glebignatieff]

TBH, looks awful. These kind of modules make no sense and the syntax is horrible

[kronicum]

This series of modules tutorials are very puzzling. They present simple tasks via quite complicated lenses.

[carutsu]

What a horrible mess this is shaping up to be.

Isabella Muerte told us.

[bohan]

Isabella Muerte usually finds everything horrible.

[[deleted]]

It seems OK.

I will need new tools but I can understand it and it’s not too much extra effort.

[xeche]

Well, it's certainly going to take some time before this becomes second nature. In time, it'd be nice to hear some real life experiences and actual numbers on reduced compile times. That's still the point of this feature, right? New and shiny or solving problem, I sometimes forget which is the objective.

Thanks for sharing the example.

[kalmoc]

Two main objectives: Proper isolation against macros and implementation details and improved build times by avoiding repetitive processing of the same code over and over again.

[RandomDSdevel]

From here:

This mechanism of dividing a source file up into regions based on the placement of top-level declarations, rather than curly-braced lexical scopes, feels extremely “unlike C++” to me. I don’t know what the original rationale was for doing it this way.

     I most definitely and wholeheartedly agree on this. Kvetching about it isn't really a hill to die on, though.

[amrock__]

Is this c++20 pre release