On Thu, Jan 09, 2003 at 01:31:28PM -0500, William E. Kempf wrote: > > From: "Peter Dimov" <[EMAIL PROTECTED]> > > From: "William E. Kempf" <[EMAIL PROTECTED]> > > > > From: "Peter Dimov" <[EMAIL PROTECTED]> > > > > > > > I think that a reasonable requirement that we already mentioned several > > > > times is that the ID should be CopyConstructible, Assignable and > > > > LessThanComparable, for use in sets/maps. > > > > > > Should it truly be LessThanComparable, or should it follow the design of > > > std::type_info with a before() method? > > > > Something that meets the requirements stated above can be used in > > > > std::map<K, V> > > You can do the same with std::type_info by supplying a template > parameter other than the default std::less<>. I understand this > need, and I understand how simple it is when you truly are > LessThanComparable (and lean that direction myself). I just want to > make sure that someone isn't going to argue that we should have > followed the type_info design, since there's no true ordering for > this type.
The real problem is the lack of a hash table library. AFAIK, there is no use of this type of ordering except for use in std::map, std::set. However, a tree is the wrong data structure -- tree operations (insert, find) are more expensive (O(log N)) than hash table operations (average case constant) assuming a good hash function, and the only reason to use a tree is the ordering, which is not used. Note that in order for thread to be usable in a hash table, a hash function would have to be provided or a thread id exposed. - Jeremy Maitin-Shepard _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
