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.