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