Daniel James wrote:
On 7 June 2014 17:41, Peter Dimov
wrote: While the general subject of forwarding headers still deserves consideration, in this specific case I wonder if moving funcional/hash into its own 'hash' module would not alleviate most of the problem.
The point of the forwarding header was to be a lightweight header, because the main header is quite heavy, so separating out the forwarding header is probably the right thing to do.
It's definitely the right thing to do. This doesn't mean that splitting 'hash' into its own module isn't also the right thing to do. That's what modularization means - to isolate independent components. 'hash' is completely independent of the rest of the functional library, it's even of a different kind.
Looking at your report, many of functional's dependencies seem to be caused by problems elsewhere, e.g. boost/functional/factory.hpp includes boost/pointee.hpp from iterator, which pulls in a lot of modules. I think the problem there is with boost/pointee.hpp.
boost/pointee.hpp, along with boost/indirect_reference.hpp and boost/detail/is_incrementable.hpp, are an obvious target, one that I've already identified. If you look at them, however, you'll see that they can't go to Core in their present form, as they have dependencies on MPL and TypeTraits. They will be dealt with, in due time. At the moment, I've been concentrating on (a) low-hanging fruits that (b) don't have potential to break code. 'pointee' and friends are neither. Splitting 'hash' into its own module is both. Separating hash_fwd could be, if we figure out where to put it, which I estimate will take time.