Re: [boost] [functional] How to avoid a dependency on functional?

Subject: Re: [boost] [functional] How to avoid a dependency on functional?
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2015-01-09 16:17:05

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