From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-09-04 06:40:29
In message <006a01c0165d$466b9880$3e0524d4_at_pdimov>, Peter Dimov
>Wrapping should not be necessary. The point is that to_ptr is sufficient;
>copy_to and any_cast can be implemented in terms of to_ptr.
Indeed, they are. But they are also sufficiently useful in their own
right to warrant inclusion.
>This makes copy_to even more generic.
I don't see that this actually buys me very much.
>I don't quite understand what are you objecting to.
Hacked interfaces :->
>Proper compilers would eat
>and all compilers, including MSVC, would compile the alternative
>It is a deprecated feature, granted, but this is the lesser evil.
No, the absence of deprecated features is the lesser evil. Providing a
supertype compatible interface is the more appropriate route.
Sorry to be cynical, but in most cases deprecated is another way of
saying "permanent" -- ever heard the refrain "just hack it for now, but
we'll come back and fix it later"? >:->
>> >So when you std::sort a vector of ref's, the contents are sorted by type,
>> >then by value.
>> Err, "subtle". This mixes two ordering concepts.
>No, this is a strict weak ordering on the <type, value> pair. How else would
>you make std::set<ref> work?
By providing my own function object type. I don't believe that operator<
between refs can meaningfully mix type comparison (which is not a
strictly ordered relationship) and value comparison.
>> I would argue that it's not useless, and in simple command line
>> interpreters turns out to be quite useful!
>The standard doesn't guarantee the usefulness of type_info::name(). It's
>useful if you know what your compiler does, but it's not portable.
I know that, but for a given platform this can be of use.
>Background: I'm trying to decide whether ref<> needs type_info() or not.
>This example does prove the need for any::type_info. However, ref doesn't
>need this sort of dispatch because you have access to the virtual functions
>of the base type.
Precisely, which is one of the many reasons I feel that any and ref are
quite distinct types.
Kevlin Henney phone: +44 117 942 2990
Curbralan Ltd mobile: +44 7801 073 508
kevlin_at_[hidden] fax: +44 870 052 2289
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk