Re: [boost] any

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-09-04 06:40:29

In message <006a01c0165d$466b9880$3e0524d4_at_pdimov>, Peter Dimov
<pdimov_at_[hidden]> writes
>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.

>Consider:
[...]
>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
>
>a.to_ptr<T>();
>
>and all compilers, including MSVC, would compile the alternative
>
>a.to_ptr((T*)0);
>
>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:  [phone]
  Curbralan Ltd                   mobile: [phone]
  kevlin_at_[hidden]            fax:    [phone]
____________________________________________________________