I would like to second the following: "1. The overloads of hash_value for STL containers forces the implementation to include <vector>, <list>, etc., which makes the header a little heavier than desired." I'd say it's not a 'little' heavier but a lot heavier. Can we not put the extensions in their own header files; vector_hash.hpp or something? Not everybody has all these containers in a precompiled header already. Thanks, Jaap Suter
Jaap Suter wrote:
I would like to second the following:
"1. The overloads of hash_value for STL containers forces the implementation to include <vector>, <list>, etc., which makes the header a little heavier than desired."
I'd say it's not a 'little' heavier but a lot heavier. Can we not put the extensions in their own header files; vector_hash.hpp or something?
No, this is not desirable, but the main header can probably be made to include granular <boost/hash/*.hpp> headers.
Not everybody has all these containers in a precompiled header already.
FWIW, I never use precompiled headers, and have never had problems with standard includes. That's because most translation units end up including most of the standard library anyway. But this may be just me.
Jaap Suter wrote:
I would like to second the following:
"1. The overloads of hash_value for STL containers forces the implementation to include <vector>, <list>, etc., which makes the header a little heavier than desired."
I'd say it's not a 'little' heavier but a lot heavier. Can we not put the extensions in their own header files; vector_hash.hpp or something?
Not everybody has all these containers in a precompiled header already.
While working on this I haven't been using precompiled headers at all. And my computer is pretty old. I get the impression that more time is spent instantiating templates than parsing header files. But I could be completely wrong, I haven't really tested this and it probably varies on different compilers. I think the problem with putting the extensions into a separate header is that the hash functions are intended to provide a default implementation for hash containers. Users of the library shouldn't have to think about including any headers other than the hash container's header. But it certainly is a valid option - it was the one I used when I first started on this. Daniel
participants (3)
-
Daniel James -
Jaap Suter -
Peter Dimov