Re: [boost] Re: [boost.tr1?] request for a hash<> implementation
Hi Daniel, ----- Mensaje original ----- De: Daniel James <daniel@calamity.org.uk> Fecha: Domingo, Febrero 6, 2005 7:12 pm Asunto: [boost] Re: [boost.tr1?] request for a hash<> implementation
JOAQUIN LOPEZ MU?Z wrote:
What I'm interested in in the short term is the hash<> functor alone. Of course unordered containers are much more interesting, but this will have to undergo the usual review process, I guess. Do you think we can put your hash<> implementation under boost/functional/hash.hpp and have some short docs for it?
I've just uploaded a new version. I've rewritten the hash functions based on Peter's design. I'll write some documentation and some more tests soon.
You've been fast! I've taken a look at your stuff and have a couple of concerns/suggestions: 1. Now the file is boost/hash/functional.hpp. Wouldn't it be better to call it boost/functional/hash.hpp? As I see it, hash<> is part of TR1 future <functional>, so the naming I propose looks more consistent. 2. The header includes <set> and <map>, which can be quite heavy if the user has no intention to use the corresponding hash_value overloads. Alas, I don't know of any way to avoid the inclusions, since a forward declaration of these containers can fail due to the freedom stdlib implementers have to add additional template parameters to those specified by the standard. Any idea? I'll soon bundle your header with a preview of hashed indices for Boost.MultiIndex, probably the next week. Thank you so much for your effort, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
JOAQUIN LOPEZ MU?Z wrote:
You've been fast! I've taken a look at your stuff and have a couple of concerns/suggestions:
Not that fast, most of the implementation is just copied out of Peter's specs. By the way, don't put much trust into the hashes for floats yet. I should have mentioned that before. I'll write more tests for them before you release anything properly.
1. Now the file is boost/hash/functional.hpp. Wouldn't it be better to call it boost/functional/hash.hpp? As I see it, hash<> is part of TR1 future <functional>, so the naming I propose looks more consistent.
Yeah, I'll do that. Although, until it's formally a part of boost, I thought you'd just be putting it into a detail directory.
2. The header includes <set> and <map>, which can be quite heavy if the user has no intention to use the corresponding hash_value overloads. Alas, I don't know of any way to avoid the inclusions, since a forward declaration of these containers can fail due to the freedom stdlib implementers have to add additional template parameters to those specified by the standard. Any idea?
The only thing I can think of is seperating the file into two different headers, something like boost/functional/hash.hpp and boost/functional/hash_containers.hpp. But that would be pretty awkward to use. Daniel
Hi Daniel Daniel James ha escrito:
1. Now the file is boost/hash/functional.hpp. Wouldn't it be better to call it boost/functional/hash.hpp? As I see it, hash<> is part of TR1 future <functional>, so the naming I propose looks more consistent.
Yeah, I'll do that. Although, until it's formally a part of boost, I thought you'd just be putting it into a detail directory.
Well, putting it in detail defeats the whole purpose of raising a public hash implementation for use by multi_index, eventually your unordered containers and what might come in the future. My plan is to wrap your hash.hpp, docs and tests as part of the next upgrade of Boost.MultiIndex, which features hashed indices (sometime this week.) If you don't mind, of course. We can let this upgrade be submitted to an informal review before comitting to the CVS: if everybody's happy, commit and we're done. If someone raises some objection to this hash being incorporated to Boost, we'll know. On one side, library maintainers have certain degree of freedom when adding new features to an accepted library; on the other side, this could be regarded as piggybacking an unreviewed library into Boost. The only way to know IMHO is to let people decide. Is this OK with you? Comments, objections? You might want to move to private email, if this is going to generate excessive noise on the list.
2. The header includes <set> and <map>, which can be quite heavy if the user has no intention to use the corresponding hash_value overloads. Alas, I don't know of any way to avoid the inclusions, since a forward declaration of these containers can fail due to the freedom stdlib implementers have to add additional template parameters to those specified by the standard. Any idea?
The only thing I can think of is seperating the file into two different headers, something like boost/functional/hash.hpp and boost/functional/hash_containers.hpp. But that would be pretty awkward to use.
Yep, I guess there's no easy workaround. Yours, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
participants (3)
-
Daniel James -
JOAQUIN LOPEZ MU?Z -
Joaquín Mª López Muñoz