Re: [boost] [modularization] Modularizing Boost (modularization)

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 
nov1_strong.dot:

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.