Boost logo

Boost :

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-09-01 11:59:30

In message <001901c01430$7e973b80$130524d4_at_pdimov>, Peter Dimov
<pdimov_at_[hidden]> writes
>Yes, I see. So copy_to() can be implemented in terms of the public interface
>of 'any' (to_ptr). Wouldn't this make it a candidate for a free function?

Not really. Free functions are not that free: they are still part of the
interface, so the interface is the same size, and if applied
inappropriately they make the code harder not easier to follow. In this
case the simplest place to put it is in the public interface.

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

>> >(2) typical type_info() usage.
>> The following allows a simple sorting wrt type, and verification of
>> result:
>> bool type_info_ordering(const any & lhs, const any & rhs)
>> {
>> return lhs.type_info().before(rhs.type_info());
>> }
>> void print_type_info(const any & to_print)
>> {
>> cout << to_print.type_info().name() << endl;
>> }
>> void sort_example()
>> {
>> vector<any> many;
>> ... // set up with values
>> sort(many.begin(), many.end(), type_info_ordering);
>> for_each(many.begin(), many.end(), print_type_info);
>> }
>> The following demonstrates matching/filtering:
>> struct is_type : binary_function<any, const type_info *, bool>
>> {
>> bool operator()(
>> const any & operand, const type_info * type) const
>> {
>> return operand.type_info() == *type;
>> }
>> };
>> void find_example()
>> {
>> vector<any> many;
>> ...
>> vector<any>::iterator first_int =
>> find_if(
>> many.begin(), many.end(),
>> bind2nd(is_type(), &typeid(int)));
>> ...
>> }
>But note that the first example is already supported by ref<> (its op<
>compares the types of the two objects)

From what I can see, ref<> compares content and not type. It would be
counterintuitive for it to compare types not values using < and ==,

However, this was an example of one kind of predicate that I could
write, not an exhaustive list of the only one :-)

>and the second can be easily done
>with ref::is<int>, or any::to_ptr<int>.

The second specific example, yes. But if you are provided with the
type_info dynamically, eg to find from a list, to_ptr will not save you.
Overall, given the dynamic nature of the type, it's easier to reflect
C++'s meagre reflection capabilities to the fullest.

>I was thinking of an example that
>demonstrates the need for the type_info() function.

Toy examples have to be liberalised a little to get the full effect, but
the point is that not everything can be done with compile-time binding,
which is what to_ptr offers, and some things need runtime binding, which
is what type_info offers.

Taking a step back, I would find it odd that a type that can hold
anything and knows what it holds is gagged from being able to tell you
its content!

>Having a minimal
>interface is good, isn't it?

Yes, which is what we've currently got: anything less is below the
minimum :-)

  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, gregod at, cpdaniel at, john at