El 09/06/2014 7:12, Stephen Kelly escribió:
Ion Gaztañaga wrote:
El 09/06/2014 0:24, Andrey Semashev escribió:
On Sunday 08 June 2014 23:53:41 Ion Gaztañaga wrote:
TypeTraits would not be MPL dependant. MPL could depend on TypeTraits and Core.
mpl::bool_ is not the only thing TypeTraits uses from MPL, so this dependency won't go that easily. This is arguably true for other libraries as well. Pulling more things from MPL to Core will make it heavier. I'd like to keep MPL stuff localized and IMHO Core is not the right place for it.
Sorry, I missed the rest of dependencies. The circular dependency between MPL and TypeTraits doesn't sound very good from a a design point of view.
If separate modules are so tightly coupled that they are inseparable, they are "incidentally" a single module (think 'incidental data structures'). Neither can exist without the other. Typeof and Core also participate in a closed dependency loop with MPL and TypeTraits. The four form one 'incidental module'.
You could decide whether absence of incidental modules is a design goal. If it is, then you can merge those four together when it is no longer possible to remove edges between them.
That would remove the number of dependencies to one giant dependency. Not very useful to reduce coupling and compilation times. Using mpl::and_/mpl::not_ instead of "&&" and "!" in TypeTraits does seem avoidable. Only CommonType seems a bit more complicated to break from MPL. But it's relatively easy to implement without MPL. Ideally in my mind: MPL --- depends on --> TTraits--- depends on --> (Traits)Core. Or even: MPL --- depends on --> TTraits--- depends on --> (Traits)Core. I think all TypeTraits dependencies on MPL are avoidable and makes Boost more layered and maintainable. Makes a lot of Boost libraries directly or indirectly independent form MPL. I haven't studied Typeof source code so I can speak about its dependencies. However, breaking dependencies will need code changes in several libraries, so we must do this with care. Best, Ion