On 10/25/2013 09:41 AM, Ahmed Charles wrote:
The main reason I moved it out in my analysis was because the exception library also has other dependencies. Of course, another option would be to split it into two libraries to isolate those dependencies. Looking at the dependencies again now, even that may be unnecessary depending on what happens with the detail and utility repos. I don't have the time to look right now, but I'd be curious why the exception library would have lots of dependencies and if it does, it would probably make sense to have it split into two, containing the basic functionality that every library needs and the advanced functionality that requires additional dependencies. For example, if you suggested a library called exception_core which contained the two headers above and everything using those exclusively depended on that library, I'd think it was perfect, because the files are logically placed and the dependency graph would be reduced to a usable state.
That could be an option. I initially wanted to move those files out of the exception library because exception brings the dependency on smart_ptr and tuple into the 'inner mesh' of (detail, utility,type_traits, smart_ptr, mpl, typeof) which I mentioned in my initial mail. Adding tuple to that might not matter as it brings in nothing not already in the mesh (just like smart_ptr as it turns out), if detail and utility can be arranged to not depend on stuff outside of the inner mesh. That's what I meant when I wrote 'Looking at the dependencies again now, even that may be unnecessary depending on what happens with the detail and utility repos.'. At least, I think discussion, moving or splitting of those exception files can be deferred or should be part of a 'boost core library' discussion. Thanks, Steve.