El 09/01/2015 a las 21:17, Peter Dimov escribió:
Beman Dawes wrote:
Filesystem has a dependency on <boost/functional/hash_fwd.hpp> in order to supply this:
inline std::size_t hash_value(const path& x) { # ifdef BOOST_WINDOWS_API std::size_t seed = 0; for(const path::value_type* it = x.c_str(); *it; ++it) hash_combine(seed, *it == '/' ? L'\\' : *it); return seed; # else // BOOST_POSIX_API return hash_range(x.native().begin(), x.native().end()); # endif } ... Is there any recommended way to avoid the functional dependency?
In this specific case, I would forward-declare hash_combine and hash_range. I already submitted a pull request against array along the same lines, which Marshall graciously accepted.
But shouldn't a function calling hash_combine include the header with the implementation (that is, "hash.hpp")? Or it is assumed that since hash_value will normally be called via ::boost::hash+ADL someone must have included it?
Had 'hash' been in its own module, I would consider simply including hash.hpp, rather than relying on forward declarations, as 'hash' should be a very lightweight module.
Not if it includes implementation for several types, and does now for standard types. including hash.hpp might import a non-negligible amount of headers. In case case, I think putting "hash" in its own module it's a very good idea, maybe with new headers in boost/hash, maintaining backwards compatibility from functional/hash includes. Best, Ion