|
Boost : |
From: williamkempf_at_[hidden]
Date: 2001-05-26 08:47:54
--- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> From: <williamkempf_at_h...>
>
> > > > C) There are plenty of other cases where this holds true. A
> > classic
> > > > example is std::type_info. Basically any type that doesn't
not
> > have
> > > > full ordering but *can* have consistent partial ordering.
> > >
> > > But std::type_info is totally ordered. :-)
> >
> > I used the wrong terminology here. I should have said strict-weak
> > ordered. The point still stands.
>
> Unfortunately the point does not stand.
>
> std::type_info is not partially ordered; it provides neither
operator< nor
> std::less; and it cannot be put in standard containers.
Notice that when using the correct terminology I don't say "partially
ordered". As for the standard not providing a std::less, that's
true, but it's likely just an oversight. A version of std::less can
be trivially added using typ_info::before() which is in keeping with
how things work for pointers that are not pointing within an array.
Adding an operator< for std::type_info would not be in keeping with
this concept, however. Scott Meyers defines a std::less for
type_info in MEC++ for this very reason. I believe the example
*DOES* stand.
> Try to provide another example of a type that should have std::less
but not
> operator<, having in mind 20.3.3/5 and 17.4.3.1/1.
>
> > > Did you read the example in my original message?
> >
> > Yes, I did.
>
> OK. Do you agree that it is a real problem? How would you solve it?
(I mean
> the problem with serializing a shared_ptr.)
Using the same techniques I'd use if raw pointers were being used
instead. Seriously, the example given is a very non-trivial example
and knowing if an object has been previously serialized is not going
to be enough info to persist the containing object any way. In a
case like this you'll have to maintain more info in
seperate "database" any way, so I'd rely on it for everything. I
don't find the example a compelling example for the need to expose pn.
Bill Kempf
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk