c++ modules design in case of proposal N2073 and as a whole

Question

There are always been some talks about modules in c++. But yesterday(shame on me that only yesterday) I met this thread with link to c++ modules proposal.

It was something like "Boy oh boy!Finally there will be something about realisation or desing and some interesintg ideas..."

At that moment I must ask to excuse me for futher rage...

I'v read it twice.

There are following benefits as author says:

• Significantly improve build times of large projects (Olalal i though there!That will be awesome...)

• Enable a better separation between interface and implementation

• Provide a viable transition path for existing libraries

• Shielding from macro interference

• Shielding from private members

• Improved initialization order guarantees

• Avoidance of undiagnosed ODR problems

• Global optimization properties (exceptions, side-effects, alias leaks,…)

and some others mentiond algon the text.

(sorry again for an angry tone)

Ehm...to be honest I dont realy care about how does his tricks with import/export look like(confusing or not it doesn't matter), don't care about visibility,hiding, e.t.c I dont care about some things like static init block that do exist in java and some others.

But the MAIN GOAL, the CORE of the modules should be compilation speed, here it mentioned:

• Significantly improve build times of large projects

All those movements without compilation speed improvements are useless. Its a drivel.

I'v read it twice as i said.

And there is absolutely NOTHING usefull about hot to implement modules to achieve speedup. I was just "What? Are you kidding?"

QUOTE: Modules address this issue by replacing the textual inclusion mechanism (whose processing time is proportional to the amount of code included) by a precompiled module attachment mechanism (whose processing times can be proportional to the number of imported declarations). The property that client translation units need not be recompiled when private module definitions change can be retained.

We know the goal. But where is something except "it should?"

I don't know mb the propsal goal is just to say "He what you think about the idea?" but I though there will be somethinkg like RFC. Seems I'v been wrong.

So in case of such situation I just wanted to ask community few very basic questions, because I dont really understand how modules can be implemented without rewriting from scratch huge part of the languagae and all compilation and linking mechanism we have today. Really I dont understand :( And does such huge effort worth it? This will be completeley different language... what is the reason saying "evolved c++"?

It goes without saying that to realise modules there should be some kind of data format those modules are written, some metadata. Ok. It can be plain text isn't it? It serves the goal, but ofc NO! That way there will be another import->import->ipmport plain text chains which should be parsed at compile time. So seems there should be binary data:) Ok. Should it be only language specific and crossplatform or platform specific?

Then what about all those #ifdef blocks in code? If there will be some sort of precompiled binary data, it will be or platform dependent (and ultra all including all the ifdef branches in the world) or it will be strange module which we should recompile every time. Seems it couldn't be true. What about that aspect? Or saying modules in c++ we dont talk about platform independent metadata at all, we are just talking about some kind of precompiled data, which will be usefull ONLY in recompilation stage of the same project? There is no java-like machine to exclude some branches at runtime isn't there?

How on earth it could be created? At les the main idea :)

And what about all that library implimentations? .dll, .a, .so? e.g. nowdays we have sources+headers(+headers+headers+headers) -> obj -> binary. Where is the place of c++ modules in that chain? How does it should look like? sources->obj+modules-> binary? or sources->modules+modules->objs->binary ?

Seems implemeting modules in any way will affect all the compilatin process we use today.

In summary I just interesting in base concept but something a lit more constructive then "oh it should decrease compilation time" - thats not serious! And hope someone can share some knowledge or conceptions (or point the right way for it) about how it can bea realised.

Tnx in advance!Hope I would not be banned away :(

Answer 1

First off, please note that N2073 is rather old! The latest module proposal I'm aware of is N3347. Of course, this also only talks about language level constructs. The same will be true for all other papers on this topic (or any other topic for that matter): The language standard doesn't specify at all how the language is implemented. What the C++ standard specifies is what the semantics of the language are. How that is implemented is up to the compiler writers and, to some extend, to the people defining a software development platform: For a given platform there may be specification how different compiler interoperate. If modules get included into the language standard this is where things like file formats would be defined.

That said, note that specifying the semantics on how modules are to be represented on a language level gives compilers the nececessary leverage to create an efficient representation (assuming it is done right, of course). At the moment, any odd #define can warp around lots of declarations and make it entirely unpredictable how the declarations in a given header will look like. Of course, any sane library will impose restrictions on what a user can do but all these restrictions are outside the language specification. The moment there is a stable definition, the compiler can just load its internal data structures based on a suitable representation of a module created earlier in some way. The compiler vendors don't really need any guidance in how to make their specific compiler process modules either: They know their internal data structures much better than anybody else! ... and any fixed recipe will not work for some compiler vendors anyway.

Just a note on the representation of the content of modules: whether the representation of the declarations in a module are text or binary doesn't really matter much: In both cases the data represented will be the same and it will readily include, e.g., name resolutions and avoid any parsing quirks.

Modules is one of the topics which is on the agenda for a future revision of the standard. I haven't seen much information on the status of modules but it is a topic multiple compiler vendors are interested in. Of course, they all have different ideas what is needed and how it should look like but they agreed to cooperate.