Modules

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Modules

Boost - Dev mailing list
Hi,
Are there any guidelines on the use of modules inside boost?
Are we planning any steps for adoption of them?

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Modules

Boost - Dev mailing list
On Fri, Aug 21, 2020 at 11:55 AM Damian Vicino via Boost
<[hidden email]> wrote:
> Are there any guidelines on the use of modules inside boost?

No.

> Are we planning any steps for adoption of them?

That question is answered on a library by library basis. Speaking for
Boost.Beast, modules requires C++20 while Beast only requires C++11,
so Beast will not be "using modules" any time soon.

Thanks

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Modules

Boost - Dev mailing list
On Sat, Aug 22, 2020, 15:49 Vinnie Falco via Boost <[hidden email]>
wrote:

> On Fri, Aug 21, 2020 at 11:55 AM Damian Vicino via Boost
> <[hidden email]> wrote:
> > Are there any guidelines on the use of modules inside boost?
>
> No.
>
> > Are we planning any steps for adoption of them?
>
> That question is answered on a library by library basis. Speaking for
> Boost.Beast, modules requires C++20 while Beast only requires C++11,
> so Beast will not be "using modules" any time soon.
>

I'd rather treat C++20 modules in 2020 as C++11 rvalues in 2011. If the
compiler supports them then Boost library authors may use them in the
library and provide benefits to the end users. But they won't become a
required feature in next 20 years.

I'd expect some kind of guidelines and macro in Boost.Config as soon as we
get some compiler that properly implements the C++20 modules. Right now
there's no such compiler.

>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Modules

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Fri, Aug 21, 2020 at 1:54 PM Damian Vicino via Boost
<[hidden email]> 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.  Such macro-conditional code can be written in
headers that are #included at the top of a module, but that module
must always be built with the same definition of
BOOST_LIBNAME_DO_WHATEVER.

Of course, we have no support for modules in Boost build either, which
is what you were asking I think.  I think the motivation for all the
work that would require is somewhat low.

Zach

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Modules

Boost - Dev mailing list
> Gesendet: Sonntag, 23. August 2020 um 00:40 Uhr
> Von: "Zach Laine via Boost" <[hidden email]>
> An: "Boost mailing list" <[hidden email]>
> Cc: "Zach Laine" <[hidden email]>
> Betreff: Re: [boost] Modules
>
> On Fri, Aug 21, 2020 at 1:54 PM Damian Vicino via Boost
> <[hidden email]> 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.
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?

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.
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.

Mike


>
> Zach
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Modules

Boost - Dev mailing list
On Sun, Aug 23, 2020, 10:13 Mike via Boost <[hidden email]> wrote:

> <...>
> 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.
>

I think that it is solvable. In each header put something like that in the
beginning:

#if defined(__cpp_modules) && !defined(BOOST_VARIANT_BUILD_MODULE)
import boost.variant
#else

 // include guards
#ifndef BOOST_VARIANT_HPP
#define BOOST_VARIANT_HPP

#endif

#endif


Now `import boost.variant;` and `#include <boost/variant.hpp>` could
coexist. Also all the users just gain the benefits of modules if compiler
supports them.

>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Modules

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Sun, Aug 23, 2020 at 2:13 AM Mike via Boost <[hidden email]> wrote:

>
> > Gesendet: Sonntag, 23. August 2020 um 00:40 Uhr
> > Von: "Zach Laine via Boost" <[hidden email]>
> > An: "Boost mailing list" <[hidden email]>
> > Cc: "Zach Laine" <[hidden email]>
> > Betreff: Re: [boost] Modules
> >
> > On Fri, Aug 21, 2020 at 1:54 PM Damian Vicino via Boost
> > <[hidden email]> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Modules

Boost - Dev mailing list
> Gesendet: Sonntag, 23. August 2020 um 19:09 Uhr
> Von: "Zach Laine via Boost" <[hidden email]>
> An: "Boost mailing list" <[hidden email]>
> Cc: "Zach Laine" <[hidden email]>
> Betreff: Re: [boost] Modules
>
> On Sun, Aug 23, 2020 at 2:13 AM Mike via Boost <[hidden email]> wrote:
> >
> > > Gesendet: Sonntag, 23. August 2020 um 00:40 Uhr
> > > Von: "Zach Laine via Boost" <[hidden email]>
> > > An: "Boost mailing list" <[hidden email]>
> > > Cc: "Zach Laine" <[hidden email]>
> > > Betreff: Re: [boost] Modules
> > >
> > > On Fri, Aug 21, 2020 at 1:54 PM Damian Vicino via Boost
> > > <[hidden email]> 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

Could you maybe point me to the relevant location in the standard? A quick test with
compiler explorer (https://godbolt.org/z/EP18s1) turns not up any errors,
but of course I doubt any compiler implements modules completely to spec yet.

> [...]
>
> > 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.

Not sure to which of the two suggestions you are replying, but I really
don't understand why it should require any work for most of boost
(except maybe the PP library) to be consumable as a header unit.
And for a wrapper module, what I have in mind is something like:

module;
#include <boost/variant.hpp>
export module Boost.Variant;

namespace boost {
    export using boost::variant;
}

But I'm absolutely no modules expert.

Mike



>
> Zach
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Modules

Boost - Dev mailing list
On Sun, Aug 23, 2020 at 1:35 PM Mike via Boost <[hidden email]> wrote:
>
> Could you maybe point me to the relevant location in the standard? A quick test with
> compiler explorer (https://godbolt.org/z/EP18s1) turns not up any errors,
> but of course I doubt any compiler implements modules completely to spec yet.

No, because it looks like that changed!  The rule I had in my head is
from a previous version of the feature.  Sorry for the noise.

[snip]

> But I'm absolutely no modules expert.

Neither am I (obviously!).

Zach

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Modules

Boost - Dev mailing list
On Sun, 23 Aug 2020 at 22:34, Zach Laine via Boost
<[hidden email]> wrote:
>
> On Sun, Aug 23, 2020 at 1:35 PM Mike via Boost <[hidden email]> wrote:
> >
> > Could you maybe point me to the relevant location in the standard? A quick test with
> > compiler explorer (https://godbolt.org/z/EP18s1) turns not up any errors,
> > but of course I doubt any compiler implements modules completely to spec yet.
>
> No, because it looks like that changed!  The rule I had in my head is
> from a previous version of the feature.  Sorry for the noise.

It is, however, worth noting that if you have, say, 16 different
possible preprocessor
outputs, you can just ship one header with the preprocessor
conditionals that with their
different values give you 16 programs, but you need to ship 16 modules
to get the same
result in a modular world.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Modules

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Mike wrote:

> And for a wrapper module, what I have in mind is something like:
>
> module;
> #include <boost/variant.hpp>
> export module Boost.Variant;
>
> namespace boost {
>     export using boost::variant;
> }

Or you could just use `import <boost/variant.hpp>` and not need any
wrappers.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Modules

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Ville Voutilainen wrote:
> It is, however, worth noting that if you have, say, 16 different possible
> preprocessor outputs, you can just ship one header with the preprocessor
> conditionals that with their different values give you 16 programs, but
> you need to ship 16 modules to get the same result in a modular world.

In Boost's case, since everything includes <boost/config.hpp>, we have
millions of possible preprocessor outputs. Shipping precompiled modules for
all of these isn't going to be feasible.

We might however be able to build the modules as part of the Boost build, if
B2 evolves appropriately and compilers choose the "modules as precompiled
headers" model as the most practical.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Modules

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> Gesendet: Sonntag, 23. August 2020 um 21:43 Uhr
> Von: "Ville Voutilainen via Boost" <[hidden email]>
> An: "[hidden email] List" <[hidden email]>
> Cc: "Ville Voutilainen" <[hidden email]>
> Betreff: Re: [boost] Modules
>
> On Sun, 23 Aug 2020 at 22:34, Zach Laine via Boost
> <[hidden email]> wrote:
> >
> > On Sun, Aug 23, 2020 at 1:35 PM Mike via Boost <[hidden email]> wrote:
> > >
> > > Could you maybe point me to the relevant location in the standard? A quick test with
> > > compiler explorer (https://godbolt.org/z/EP18s1) turns not up any errors,
> > > but of course I doubt any compiler implements modules completely to spec yet.
> >
> > No, because it looks like that changed!  The rule I had in my head is
> > from a previous version of the feature.  Sorry for the noise.
>
> It is, however, worth noting that if you have, say, 16 different
> possible preprocessor
> outputs, you can just ship one header with the preprocessor
> conditionals that with their
> different values give you 16 programs, but you need to ship 16 modules
> to get the same
> result in a modular world.

Correct me if I'm wrong, but you can still ship a single module source file with all the conditional. You would need 16 different versions of the cmi (bmi) if you wanted to ship them at all (my understanding is that this is not going to be recommended practice.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Modules

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> Gesendet: Sonntag, 23. August 2020 um 23:16 Uhr
> Von: "Peter Dimov via Boost" <[hidden email]>
>
> Mike wrote:
>
> > And for a wrapper module, what I have in mind is something like:
> >
> > module;
> > #include <boost/variant.hpp>
> > export module Boost.Variant;
> >
> > namespace boost {
> >     export using boost::variant;
> > }
>
> Or you could just use `import <boost/variant.hpp>` and not need any
> wrappers.
>

That's why I previously said

> Make sure your headers can be used as header units and/or provide a wrapper module for each library.

A wrapper module has the advantage, that it creates a named module and only exports what is explicitly specified,  whereas "just" making sure the headers are importable is much easier to do, but doesn't provide the same level of isolation.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Modules

Boost - Dev mailing list
Mike wrote:
> A wrapper module has the advantage, that it creates a named module...

Depending on how chips fall I'm not sure this would necessarily be such an
advantage. Importing the header will work as long as including it does,
whereas a named module requires some sort of a module mapper, which in the
overengineered gcc implementation makes you start a local server.

> and only exports what is explicitly specified,

Yes, that's an unquestionable advantage.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Modules

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Sun, Aug 23, 2020 at 4:34 PM Mike via Boost <[hidden email]>
wrote:

>
> You would need 16 different versions of the cmi (bmi) if you wanted to
> ship them at all (my understanding is that this is not going to be
> recommended practice.
>

Not recommended is putting it mildly. For some vendors the BMI (yes, that's
what we are suggesting they be called) is intimately tied to the specific
compilation state. I.e. not just flags, but specific build of the compiler.
Hence they are equivalent to PCHs in that respect.

--
-- René Ferdinand Rivera Morell
-- Don't Assume Anything  -- No Supone Nada
-- Robot Dreams - http://robot-dreams.net

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Modules

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Mon, 24 Aug 2020 at 00:34, Mike via Boost <[hidden email]> wrote:

> > It is, however, worth noting that if you have, say, 16 different
> > possible preprocessor
> > outputs, you can just ship one header with the preprocessor
> > conditionals that with their
> > different values give you 16 programs, but you need to ship 16 modules
> > to get the same
> > result in a modular world.
>
> Correct me if I'm wrong, but you can still ship a single module source file with all the conditional. You would need 16 different versions of the cmi (bmi) if you wanted to ship them at all (my understanding is that this is not going to be recommended practice.

This is not a correction; you're right. So the sane alternatives are
either continuing to ship a header and tell users
to just import it, or telling users that they're no longer in a simple
"just include/import one file" world and that they now
need to build source files in order to get the library parts. Which is
different from telling them to link to a library.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Modules

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 24/08/2020 06:34, Mike wrote:
> Not sure to which of the two suggestions you are replying, but I really
> don't understand why it should require any work for most of boost
> (except maybe the PP library) to be consumable as a header unit.

I haven't really been following modules, so someone please correct me if
I'm wrong, but I thought that the point was that they insulated both the
inside and the outside from stray symbols.

So if the module interface prefix explicitly #includes a "config.h" file
then any symbol in that will be visible to both users of the module and
the implementation of the module; but if user code #included "foo.h"
before importing the module then anything in foo.h would not be visible
inside the module.  Similarly for #defining anything outside the
interface file.

Most of Boost.Config and other macros would be fine with this, since
they're detecting compiler capabilities that aren't really customisable
(although some may depend on compiler parameters, which gets tricky;
this includes things like -std=).

But this would break a lot of other configuration macros like
BOOST_NO_EXCEPTIONS and BOOST_THREAD_VERSION (where they exist
explicitly for the app to indicate a preference, or are intended to be
influenced by both capabilities and preferences).

Perhaps if Boost.Config always explicitly included some well-known
header file name (that could somehow be overridden by the app), with a
requirement to put all config macros only in there.  But then whatever
builds the modules would need to happen on a per-consuming-app basis
(which may defeat people who want to run b2 only once to build all the
libraries and then consume them from multiple apps).

I think you can still do the ABI-namespacing tricks to work around some
of this (such as having your module export both "v1" and "v2" at all
times in different namespaces, but then use macros in a plain header
file to control which are actually visible to the consuming code via
aliases based on the #defines in effect at the time).  But this seems to
me to at some level defeat the point of doing modules in the first place.

If modules do end up requiring an explicit build step then they also end
up turning "header only libraries" into just another kind of static
library -- with some advantages and disadvantages over real static
libraries, perhaps, but mostly disadvantages over traditional
header-only libraries.

Hopefully, I'm missing something.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Modules

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Mike wrote:

> Not sure to which of the two suggestions you are replying, but I really
> don't understand why it should require any work for most of boost (except
> maybe the PP library) to be consumable as a header unit.

At the moment I have no idea yet how a standard module implementation would
work in practice. Trying to use Boost with the Clang (pre-standard) module
implementation generally runs into two issues: headers that aren't
standalone, and ODR violations (usually caused by inconsistent macro
definitions).

You also need to mark headers that are included multiple times (as part of
file-based PP iteration for example) as "textual", but the standard impl
probably won't need it.

Someone needs to try it and see, I suppose.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost