Why do you think I said I didn't want to get into this debate? I'm sympathetic -- I don't have time for this either, but I didn't feel
On 2/1/2012 3:59 AM, Daniel James wrote: that leaving these points of your justification unanswered was responsible.
I do realise that there's a lot to say, and I don't have any enthusiasm for saying it. I wrote the thing 7 years ago.
I've made lots of much worse errors in the past -- nothing wrong about that. And you are to be commended, like all the Boost library implementors, for having made a substantial contribution. If you don't want to defend the decisions you made, though, just admit to misjudgement or let it pass.
IMO a more appropriate forum would be one of the C++ newsgroups, as this is more about how the standard should be implemented, rather than my particular implementation which should really become obsolete over the coming years. Boost.Hash's advantages over standard implementations are its portability and its customisation abilities.
The quality of the Boost implementation and whether it conforms to the requirements and Boost quality standards belongs in the Boost list. There may also be a place for part of the discussion in more general C++ lists, if the belief that the specs imply low quality hash functions is widespread in the community. Could be, but I have no evidence to that effect. The point is that there is a case to be made that this implementation should have been obsolete seven years ago at its birth. That this wasn't caught by the community back then is a failure of the whole community -- especially those of us who know something about the subject, even those like me whose community participation is sporadic. We can't do anything about the last seven years, but I think that it is clear that it should already be considered obsolete, and that replacing it should be a group priority. Unfortunately, my clients would be justified, I'm afraid, in considering the time I've spent writing on this as being somewhat irresponsible to them (deadlines long since unmet on work already paid for). If someone hasn't done something when I come up for air, I'll see about fixing this myself. As for its customisation (cap)abilities you argued earlier in the same message that a major aspect of its customizability is that it can be replaced with something else.