$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] [modularization] Modularizing Boost (modularization)
From: Stephen Kelly (steveire_at_[hidden])
Date: 2013-11-01 09:41:01
On 11/01/2013 01:50 PM, Peter Dimov wrote:
> Stephen Kelly wrote:
>> The 'new' flyweight dependency on smart_ptr was actually already
>> pre-existing, but my script missed it before. Similar is true for the
>> function and multi_index dependencies on smart_ptr:
>>
>> flyweight/refcounted.hpp:#include <boost/detail/atomic_count.hpp>
>> flyweight/detail/recursive_lw_mutex.hpp:#include
>> <boost/detail/lightweight_mutex.hpp>
>> function/function_base.hpp:#include <boost/detail/sp_typeinfo.hpp>
>> multi_index/detail/safe_mode.hpp:#include
>> <boost/detail/lightweight_mutex.hpp>
>>
>> Including detail headers from another library is a code-smell.
>> Something is might be wrong.
>
> atomic_count, lightweight_mutex, sp_typeinfo are all components that
> I've written in the course of writing and maintaining SmartPtr, but
> they are useful on their own and do not depend on anything (which is
> why they're included from detail/ and not smart_ptr/detail, which
> would indeed be a cause of concern.)
>
> lightweight_mutex, for example, is a mutex that is header-only,
> whereas using the Boost.Threads mutex would introduce a dependency on
> the compiled library (and who knows what else.)
>
> sp_typeinfo is a type_info wrapper that works when RTTI is off.
>
> Just moving these headers somewhere else will break the module-level
> dependency to SmartPtr but will introduce a module-level dependency to
> SomewhereElse, and I doubt that this will be an improvement. In
> addition, I'll then have to co-maintain SomewhereElse.
My gut tells me it would be an improvement.
Nevertheless, thanks for all the info.
Steve.