C++ 20 modules

[Thiago Adams]

Does modules in C++ specify how they could be distributed ?
Something like a package?

Does modules have influence in the build? For instance, if I include a module
the compilers knows what lib it has to include?

I cannot see any motivation for modules apart of (fast compilation
and hiding macros).

Can someone help ?
Some links or documentation?

[David Brown]

I think compiled modules are considered compiler-specific, and are not
portable. The disadvantages of this are clear - the advantages are that
they can include extra information in internal formats, such as LTO data
or compiler-specific extensions.

The motivation for modules is better modularisation - as you say, faster
compilation and hiding macros (and other internal symbols). This in
turn makes it more practical to have header-only (or header-mostly)
files and libraries, which are easier to distribute, and give more
compile-time checking and more optimisation, but are costlier for
compilation.

I don't think modules are a revolution, but they make some things a bit
neater and a bit faster.

That's my understanding, anyway - without having used them as yet.

[Juha Nieminen]

Thiago Adams <thiago...@gmail.com> wrote:
> I cannot see any motivation for modules apart of (fast compilation
> and hiding macros).

Many more modern programming languages (including the "C-like" or "C'ish"
languages) do not use header files to declare their public interfaces.
In essence, the public interface visible to other modules/compilation units
is kind of "generated automatically" from the source file itself.

While there are some situations where C style header files can be useful
and practical, probably in more than 99% of cases they are completely
extraneous and there's no reason why a mechanism couldn't exist that kind
of generates them automatically from the source file (not necessarily as
a literal file, but as some kind of metadata that acts in the same way as
a properly-designed header file does).

C style header files have a lot of problems.

For starters, many people use them wrongly (quite often so with beginners,
but sometimes even for more experienced programmers). One could think
rather elitistically "who cares if somebody uses them in the wrong way?
They should just learn to use them properly!" but we shouldn't dismiss
language design decisions that naturally lead to better code, and naturally
make people avoid bad code.

For example, it's a quite common misconception amongst beginners (both in
C and C++) that *all* type, function and class declarations used in a
source file should be put in the header file. That the header file is
kind of like the place for those. They fail to understand the concept that
a header file is not "a file where all declarations go", but it's the
public interface of the module. The part of it that should be visible
to other modules. Thus it should be as minimalistic and clean as reasonable,
and not contain any internal implementation details that are either not
used or not needed elsewhere.

Even many more experienced programmers haven't learned this and still
dump everything that the source file uses in the header file, with little
to no thought paid to actually designing a good public interface.

Of course there's then the technical problems with header files, like the
problem of recursive inclusion, which is pretty much always an error,
but which is usually very hard to find out the problem because it causes
really strange and confusing errors about missing names that "quite
clearly" shouldn't be missing. Code that has been compiling just fine for
months, and has not been modified in any way, may suddenly out of the
blue start giving strange errors about missing names, because of a change
in a seemingly unrelated header file somewhere else entirely.

Include file dependency explosion is also a problem that very few C and
C++ programmers pay attention to, but which genuinely can cause enormously
longer compile times in large projects because of just one little change
in one single header file. There are many techniques that can be used
to significantly reduce include file dependency chains, but most
programmers don't bother, and many aren't even aware of the problem or
know the techniques to alleviate it.

[Brian Wood]

On Thursday, October 8, 2020 at 8:29:27 AM UTC-5, thiago...@gmail.com wrote:
> Does modules in C++ specify how they could be distributed ?
> Something like a package?
>
> Does modules have influence in the build? For instance, if I include a module
> the compilers knows what lib it has to include?
>
> I cannot see any motivation for modules apart of (fast compilation
> and hiding macros).
>

For years I was looking forward to them, but they are
so slow in coming that I don't think about them much
now. Maybe in a few years it will be different.


Brian
Ebenezer Enterprises
https://github.com/Ebenezer-group/onwards