Re: On Boost and modules

From: Robert Ramey (ramey_at_[hidden])
Date: 2024-04-08 18:29:31

On 4/8/24 10:30 AM, Andrey Semashev via Boost wrote:

> I find the fact that modules, including std, are not redistributable and
> that they must be built for every project extremely disappointing. I
> suspect, this will negate the potential benefit from reducing parsing
> when large projects like Boost are consumed as modules. Remember that we
> typically use only small portions of Boost, or even small portions of
> select Boost libraries. It doesn't make sense to have to build the whole
> Boost into a module only to pull a small part from it. I would much
> rather include the headers I want instead.
> 
> This is also relevant to the standard library. Will we have to build the
> ever-growing std module every time we need a smallest thing from the
> standard library? This sounds like a disaster to me.
> 
> One other thing that isn't clear is how modules interact with compiled
> libraries. I don't suppose modules will replace static/shared libraries,
> so I presume a module will be added on top of the library? How should it
> "export" the symbols that are already exported from the compiled library
> then?

The more I read this thread, the more it seems to me that modules are 
just a bad idea.  We already have shared libraries which are 
redistributable and that's already a hassle given all the compiler 
switches.  shared libraries have the same issue in that if one only 
want's to use one function, the whole library has to be shipped.

The complaints regarding compile times are not even valid as far as I'm 
concerned.  I've been on jobs where the "product" has compile times as 
long as 12 hours.  It seems to always turn out that this is due to lazy 
programmers just including too much, ("convenience" headers), including 
the same thing over and over again (header only libraries), not 
understanding basic ideas like PIMPL, and not understanding the 
libraries they are already including, avoiding re-factoring when it's 
called for (they can't do it because they didn't document the libraries 
they included in the first place), not understanding and using explicit 
instantiation in the right places, etc. I don't think there is any way 
to fix all by just including some new already overly complex facility. 
Compiler vendors aren't helping either.  How is it that they can't get 
it together and agree on a syntax for declaring visibility on library 
functions and types? How about some system to guarantee that compiler 
switches are compatible for imported code - be it in shared or unshared 
libraries?  Then there is the committee.  Stop with the doo-dads like 
three way if and stuff like that.  Spend some more time thinking about 
making constexpr more automatic and still backward compatible and maybe 
more exportable.

As for Boost, using our toolset has been a 22 year wrestling match.  It 
looks like I need to rebuild b2 (bootstrap) when I update to the latest 
boost because there's some coupling somewhere.

I could go on - but I'll quit while I'm ahead.

Robert Ramey