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
flyweight/detail/recursive_lw_mutex.hpp:#include function/function_base.hpp:#include multi_index/detail/safe_mode.hpp:#include 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.