|
|
Boost : |
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk