Re: "any" now in CVS

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2001-07-07 02:10:39

>   From: "George A. Heintzelman" <georgeh_at_[hidden]>
>I've been using the any.hpp currently out there quite successfully for 
>a little while. There are two main complaints that I have with the 
>current implementation. The first is easy to fix: for those situations 
>where you know for some reason what type is contained in the any, you 
>should be able to cast it without the overhead of checking the typeid, 
>which can (fer ex, in gcc) involve an expensive string comparison. 

Have you managed to demonstrate a significant overhead? I have not had
the chance to perform significant performance checks, but across a
couple of compilers I found a conversion to be between 50% and 200% more
expensive than the equivalent unchecked versions. For the kind of type
that boost::any is, and the places that it would be used, this does not
strike me as a problem.

>So I 
>add an 'unchecked_any_cast' as a friend:
>
>    template <typename ValueType>
>    ValueType unchecked_any_cast(const any & operand) {
>      return static_cast<any::holder<ValueType> *>(operand.content)->
>held;
>    }
>
>This is pretty dangerous, I'll grant, and if you screw it up you're 
>definitely into undefined-behavior land. Hence the long, 
>easily-greppable name. But I think that at least supplying this 
>capability will satisfy the pedal-to-the-metal sorts.

This is indeed ruthlessly dangerous >:-> I'm unsure that I have yet seen
a case where the small economy would warrant the significant loss of
safety.

>The second complaint is a little harder to deal with. I often store 
>fairly small objects in the any -- ints, floats, doubles, std::strings. 

I would not generally put std::string in the category of "fairly small".

>In these cases, the any is a pointer to an object the size of a 
>pointer, and involves unnecessary dynamic memory allocation. I would 
>like to see investigated an any implementation where the type is stored 
>in the object proper, and 'small' objects are likewise stored in the 
>objects. It seems like a no-brainer to store objects up to 
>sizeof(pointer) in the object proper (giving the any a 
>2*sizeof(pointer) on most implementations), but where to draw the line 
>is probably a question of the specific usage.

As Peter pointed out, this is perhaps not as trivial as it might first
appear. For one thing you need to deal with assignment and copy
construction cases. From my simple performance measurements, it is also
not worth it. It would also make the code for boost::any an unsightly
mess of special conditions.

>Right now, my application using the any-type is not particularly 
>CPU-bound, so I haven't had a strong impulse to attempt this myself, 
>but if any is moving towards official adoption into boost, I might be 
>talked into doing this myself.

It has been officially adopted ;->

>Finally, I have one suggestion for longer range work. One use of the 
>any-type is in returning values from database queries, where the C++ 
>code doesn't necessarily know what it will get back. 

Yes, this is one context that I had in mind for boost::any.

>In that context, 
>one will often get returned arrays of many objects of a single, unknown 
>type. It seems silly to store the type of these objects repeatedly. 
>Thus, it would be useful to have an any_array type as well, or perhaps 
>an any-adapter for STL containers, though some thought needs to go into 
>how to do that correctly.

I believe Peter's suggestion of vector<T> (or list<T>, or...) would
offer you the appropriate flexibility, whilst also making the most of
the standard library.

Kevlin
____________________________________________________________

  Kevlin Henney                   phone:  [phone]
  Curbralan Limited               mobile: [phone]
  mailto:kevlin_at_[hidden]     fax:    [phone]
  http://www.curbralan.com
____________________________________________________________