Re: [boost] any

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-09-01 04:09:35

In message <v03110700b5d46b34744f@[153.32.222.4]>, Jesse Jones
<jejones_at_[hidden]> writes
>>In this case I would have said that the implicit conversion is benign,
>>so I don't see a problem.
>
>Most of the time you're probably right, but it does introduce a hole in the
>type system. For example if someone is transitioning code from using
>void*'s to any they might run into trouble.

Most of the time I'm probably right, and in this case I'm definitely
right ;-) It introduces no hole in the type system and is safer than
using operator bool, of which it is the (more) moral equivalent. I
cannot see how anyone could genuinely run into trouble using it in the
context you describe, w/o first running into compilation errors.

>Yeah, supporting the conversion and empty is a bit silly. But if you have
>empty you don't need the conversion operator. :-)

Having the UDC allows condition declarations, amongst other things.

>>>2) I think all the type_info stuff can be replaced with a single
>>>dynamic_cast in to_ptr.
>>
>>Yes it can, but it doesn't buy you anything, which is why it is the way
>>it is :-)
>
>Sure it does. You can remove two methods and 14 lines of code. Not a huge
>savings, but the class is small enough that this does make a difference.

OK, I'm with you now: I thought you were referring to to_ptr on its own,
in which case the use of dynamic_cast would buy you nothing as it would
be (likely) less efficient and would fail to reuse the facilities
already defined in the class.

However, what you're actually suggesting is getting rid of type_info
altogether? Why would I want to do that? There would be no convenient to
discover the typeid of the content. In other words, "Hey, any, what do
you contain?" "Dunno, let's play 20 questions and maybe you can find
out!" :->

>>>3) to_ptr seems like it would be better off as an internal method that
>>>clients shouldn't call.
>>
>>Why?
>
>Providing three ways to get at the value seemed a bit excessive.

Each is different wrt (1) returning mechanism and (2) failure:

(i) any_cast returns by copy construction on success, and throws an
exception on failure.

(ii) to_ptr returns a direct pointer to the content on success, and null
on failure.

(iii) copy_to 'returns' by copy assignment to an argument, returning
true on success and false on failure.

If I needed only one I would have only one, but experience with the
class (and its ancestors) has taught me that these are reasonable
scenarios to pander to.

>get isn't clumsy in this case. any contains a single value and if you want
>to access it you call get. What could be simpler? copy_to does convey a bit
>more information, but clients will rarely care about the details of how the
>value gets returned.

copy_to allows test and assign, and has slightly more specific
requirements on its ValueType argument than either any_cast or to_ptr.

The reason I said that get was a poor name is that, depending on context
and convention, it either has a side effect or, err, it doesn't. In
other words, in some cases get is a pure query and const (eg
auto_ptr<>::get), and in others it isn't (eg basic_istream<>::get). This
is why I tend to avoid get where possible: It doesn't communicate
unambiguously.

So, following this rather wide range of prior art convention (or lack
of), reveals that the only gets in the std library that write to their
arguments are the ones that have side effects, which is definitely not
the case with any::copy_to. And they don't return a status.

The closest you can find in semantics to an existing name is
basic_string<>::copy, which is warm but not hot ("copy from" or "copy
to"?). Hence, copy_to.
____________________________________________________________

  Kevlin Henney                   phone:  [phone]
  Curbralan Ltd                   mobile: [phone]
  kevlin_at_[hidden]            fax:    [phone]
____________________________________________________________