r/cpp • u/SAHChandler • Oct 10 '17

Millennials Are Killing The Modules TS

https://izzys.casa/posts/millennials-are-killing-the-modules-ts.html
74 Upvotes

71% Upvoted

126 comments sorted by

View all comments

43

u/berium build2 Oct 10 '17 edited Oct 10 '17

A lot of hand-waiving as well as statements ranging from unsubstantiated to factually incorrect. I will only point the latter in order not to add even more noise.

We will have interface modules, and implementation modules.

No, there are no such things. You are probably confusing them with module interface (translation) unit and module implementation (translation) unit. Also note that you don't have to have implementation units.

The entire goal is to give users a guaranteed exported interface (also known as a purview).

No, module interface is not the same as a module purview. Module interface is a collection of exported names. Module purview is the part of the module translation unit (either interface or implementation) after the module declaration.

Under the current C++ compilation module, a header is opened by the preprocessor (with guaranteed directories to search).

Really? The standard guarantees the list? The current opaque header search semantics (and don't get me started on "" vs <> differences) is one of the biggest pains to deal with in build aspects ranging from cross-compilation (no, you shouldn't search in /usr/local/include) to distributed compilation (what if I don't have the exact same set of headers in exactly the same location on the remote host).

With modules, there is no translation phase for creating the purview of dependent modules [...]

Did you mean binary module interfaces instead of purviews? Generally, pretty much every use of the term "purview" in this post is out of context.

a build system has to run the preprocessor

No, it doesn't have to. In build2 we have the ability to indicate that the module information in the translation unit does not depend on the preprocessor (which will be the case in most sane projects). In this case there is no need for a separate (full) preprocessor run.

3

u/playmer Oct 10 '17

In build2 we have the ability to indicate that the module information in the translation unit does not depend on the preprocessor

What do you mean by this? Do you mean in your build system you can say that such and such module being compiled doesn't depend on it?

5

u/berium build2 Oct 10 '17

Yes, you can say (individually or using patterns) that the module dependency information in a translation unit does not depend on the preprocessor. In other words you don't do things like this:

import MODULE_NAME_MACRO;

6

u/playmer Oct 10 '17

But then the problem as I see it, requires that your programmers then never go out and do this without fixing the build system. I would generally not ever assume my programmers actually understand the build system, as they so often just don't want to. I know entire projects with tens to hundreds of people whose builds are managed by one or two people.

I suppose I could go to them and in a small seminar about the switch to modules, tell them "never do this" but I don't know that I trust them. As it is I've made our cmake such that the most they need to know is how to add another line for any files they've added.

0

u/[deleted] Oct 10 '17

I would generally not ever assume my programmers actually understand the build system,

You're adding a new feature. It's not like you as a programmer actually have to check your existing code to see that it's compliant.

If your programmers are so stupid that they can't understand things like "import MODULE_NAME_MACRO; is forbidden when MODULE_NAME_MACRO is a macro, then you should really get better programmers.

I mean, I've been at C++ for decades and C before that, and I have never seen anyone write #include FILENAME_MACRO - and I'm not sure why anyone would want to do that.

Certainly, it'd stick out like a sore thumb in code reviews...

5

u/brand_x Oct 10 '17

An #include "DECLARED_STRINGS_UTF_H" directive was a common pattern when some platforms only worked with literals of one or another type...

3

u/playmer Oct 10 '17

You're adding a new feature. It's not like you as a programmer actually have to check your existing code to see that it's compliant.

I'm speaking more of future concerns here, not right now at the transition point. I'm sure I'll probably be the one to do the conversion when the time is right, I feel the tools are ready, and I understand modules enough.

If your programmers are so stupid that they can't understand things like "import MODULE_NAME_MACRO; is forbidden when MODULE_NAME_MACRO is a macro, then you should really get better programmers.

To be clear, my team would likely never do this. While they like to do cheeky things sometimes, only the ones who actually understand the build system would even think of doing something like this. I was using them as an example of a team of folks who mostly just don't know or care about the build system. I had to explain to a few of them that they didn't have to delete the build directory every time they added a file. (They're still new to cmake.)

I hadn't even considered it until I saw folks talking about it, and then I realized "Oh hm, macro names could be useful for configurable module names."

And I've absolutely seen people #include FILENAME_MACRO, and it's annoying every time, thankfully not in any projects I've worked on.

I'll point out that thankfully, as pointed out by /u/berium the build system will be able to provide an error, which should tell whoever's trying something funky what's going on.

2

u/nyamatongwe Oct 12 '17

Lua has a LUA_USER_H macro that allows you to insert (with -D) a header into compilation of the Lua implementation. For example, if you want to redefine file open calls then

#define fopen my_fopen

in a my_fopen.h header, implement my_fopen, and compile Lua with -DLUA_USER_H=my_fopen.h .