Boost logo

Boost :

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-09-02 04:23:42


In message <005801c01439$92471fc0$130524d4_at_pdimov>, Peter Dimov
<pdimov_at_[hidden]> writes
>Having copy_to as a free function makes it easier for somebody to make it
>work with, say, ref<void> instead of any.

Well, there's nothing preventing anyone from wrapping it :-)

>> As another point, I intend for the hacked VC6 version to not offer
>> to_ptr and offer any_cast and copy_to as the sole means of accessing the
>> content.
>
>Don't do this. :) Look at the ref::is<T> workaround.

I would prefer not to provide a hacked interface with deprecated
features if possible (and I believe it is), and instead provide an
interface that is a proper supertype of the full one.

>ref<>'s operators compare types; if the types are equal they invoke the
>corresponding operator on that type, supplying a default in the case where
>no such operator is defined for the type.
>
>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.

>However, you can't do anything generic with an 'any', regardless of
>whether you have its type_info or not, except getting its name() (which is
>useless anyway.)

I would argue that it's not useless, and in simple command line
interpreters turns out to be quite useful!

As for not being able to do anything, what about keying into lookup
tables?

>That's why I asked for an example that clearly demonstrates that the ability
>to ask an 'any' for its type_info is a part of the minimal interface. So,
>what are those things that need runtime binding? :)

map<const std::type_info *, handler, type_info_before> handler_table;
____________________________________________________________

  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