Re: Modules

From: Zach Laine (whatwasthataddress_at_[hidden])
Date: 2020-08-23 17:09:06

On Sun, Aug 23, 2020 at 2:13 AM Mike via Boost <boost_at_[hidden]> wrote:
>
> > Gesendet: Sonntag, 23. August 2020 um 00:40 Uhr
> > Von: "Zach Laine via Boost" <boost_at_[hidden]>
> > An: "Boost mailing list" <boost_at_[hidden]>
> > Cc: "Zach Laine" <whatwasthataddress_at_[hidden]>
> > Betreff: Re: [boost] Modules
> >
> > On Fri, Aug 21, 2020 at 1:54 PM Damian Vicino via Boost
> > <boost_at_[hidden]> wrote:
> > >
> > > Hi,
> > > Are there any guidelines on the use of modules inside boost?
> > > Are we planning any steps for adoption of them?
> >
> > Modules are pretty hard for most Boost libs to adopt.  Consider how
> > many times we have code like this:
> >
> > #if BOOST_LIBNAME_DO_WHATEVER
> > some_code;
> > #else
> > come_other_code;
> > #endif
> >
> > That cannot exist inside a module.  The net result is that your code
> > has to be all the same lexically -- for all compilers and platforms --
> > if it is in a module.
>
> Are you sure? I've never hear of such a restriction.

Yes, although it may not be clear what I mean.  You can only have
preprocessor directives before the keyword module:

#ifdef SOMETHING // ok
#include "foo.h" // ok
#endif // ok

module foo;

#ifdef SOMETHING // error
#include "bar.h" // error
#endif // error

> And it imho doesn't make sense. Why would a compilation process on my Linux machine care, what I'm compiling on my windows machine?

It doesn't.  The net result is just that this kind of platform
specific stuff has to come in the module prefix.

> I'm probably misunderstanding what you are saying- can you give an example of code that will not compile with modules?
>
> I think the real problem is that - due to the structural differences it may not be possible to conditionally turn a header file into a module interface unit just with a bunch of #ifdefs in a convenient manner, and even if you could, code using boost modules could not coexist with code using boost headers.

That's not actually the issue -- see Antony's post.

> However,  you should be able to do the same as other legacy libraries: Make sure your headers can be used as  header units and/or provide a wrapper module for each library.

Right, it's just that if you have lots of code in common, but just
want it to vary a bit, you have to put that code in the module prefix
and then export it from the module.  It's not the end of the world,
but it is anti-idiomatic to all teaching you're likely to see about
how to write modules.

Zach