Boost logo

Boost :

Subject: Re: [boost] [modularization] Modularizing Boost (modularization)
From: Peter Dimov (lists_at_[hidden])
Date: 2013-11-01 10:25:06

Stephen Kelly wrote:
> My gut tells me it would be an improvement.

Your gut is wrong, although I'm not surprised one bit by your assumption
that I'm careless about dependencies. It's very much in line with your
general behavior so far.

These are the dependencies of SmartPtr at the moment according to

smart_ptr -> exception
smart_ptr -> type_traits
smart_ptr -> detail
smart_ptr -> utility

->exception is unavoidable because of throw_exception. ->detail is
detail/interlocked.hpp (self-contained header), which I'll kill by making a
local copy. ->utility is utility/addressof.hpp (another self-contained
header), which I will likewise deal with.

->type_traits is something I reluctantly accepted when I added make_shared,
because it needs aligned storage. It brings in -> mpl -> pp, which I hate,
but at that point it was dawning on me that striving to minimize
dependencies in the current structure is a lost cause. I'll probably need to
do a local copy of type_with_alignment and alignment_of too, but that's not
going to be easy.

The best candidate for moving these headers into is utility:

utility -> exception
utility -> type_traits
utility -> mpl
utility -> iterator

which, as you can see, has more dependencies of smart_ptr even now, because

iterator -> function_types
iterator -> conversion
iterator -> tuple
iterator -> mpl
iterator -> detail
iterator -> type_traits
iterator -> concept_check
iterator -> smart_ptr
iterator -> optional
iterator -> utility

It even depends on smart_ptr.

_If_ we had a "utility" module that was absolutely required to not depend on
anything besides Config, moving such self-contained headers there would be
an improvement. We don't.

Boost list run by bdawes at, gregod at, cpdaniel at, john at