Re: [boost] Reminder: Review period for any

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-11-07 12:21:39

In message <057101c048cd$f7e63a50$b9cc63a6_at_BREYED>, Ed Brey
<brey_at_[hidden]> writes
>I think "any" should be accepted into boost.

Thanks.

>I have some issues for improvement of "any" that have not been addressed,
>AFAIK, in previous posts:
>
>1. I like exception vs. non-exception tradeoff with any_cast and copy_to.
>There are enough use cases where type mismatches are exceptional versus not,
>that it is quite worthwhile having both interfaces.  I'd like to take the
>concept one step further and propose a to_ref method.  It would be similar
>to to_ptr, except would return a reference and would throw upon trouble
>(much like dynamic_cast).  In cases where type mismatch is exceptional,
>to_ref is more appropriate than to_ptr, since to_ref avoids giving the user
>a pointer that he's not allowed to delete.

Let me think on this one for a bit.

>2. The documentation should state that the user cannot delete the object
>pointed to by the return value of to_ptr.

Yes, good point.

>3. bad_any_cast should become any::bad_cast.  One advantage would be to
>reduce the number of using declarations a user would need to be able to use
>any without boost qualifications.

It was originally like this, but on looking at the dependencies I
realised that this made the interface of any uncohesive: any::bad_cast
was unrelated to any feature in the any's interface. I moved it out, but
if we go for to_ref then it may make sense to revert.

>4. Add a templatized swap that swaps an "any" object for an
>arbitrarily-typed object, throwing on type mismatch.

Another one I'll have to think on.

>5. Negate the logic of #ifdef COMPILING_MSVC so the conforming-compiler case
>is presented first.

This was just a quick fix and I will be revisiting the macro guards
anyway.

>6. Drop the using directives from the example in the documentation, and add
>"using boost::any; using boost::any_cast;".  This will provide a good
>example of how code can be very readable without resorting to the
>problamatic using directive.

Agreed.

Kevlin
____________________________________________________________

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