Re: Re: [boost] Next revision of boost::thread

From: Jeremy Maitin-Shepard (jbms_at_[hidden])
Date: 2003-01-09 19:31:02

On Thu, Jan 09, 2003 at 01:31:28PM -0500, William E. Kempf wrote:
> > From: "Peter Dimov" <pdimov_at_[hidden]>
> > From: "William E. Kempf" <wekempf_at_[hidden]>
> > > > From: "Peter Dimov" <pdimov_at_[hidden]>
> > >
> > > > 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