Re: [boost] [any] boost::get style accessors

Subject: Re: [boost] [any] boost::get style accessors
From: Christoph Heindl (christoph.heindl_at_[hidden])
Date: 2010-04-30 02:02:54

On Thu, Apr 29, 2010 at 6:50 PM, Stefan <mstefanro_at_[hidden]> wrote:
> vicente.botet wrote:
>>
>> ----- Original Message ----- From: "Christoph Heindl"
>> <christoph.heindl_at_[hidden]>
>> To: <boost_at_[hidden]>
>> Sent: Thursday, April 29, 2010 5:50 PM
>> Subject: Re: [boost] [any] boost::get style accessors
>>
>>
>>
>> On Thu, Apr 29, 2010 at 1:10 PM, Stewart, Robert <Robert.Stewart_at_[hidden]>
>> wrote:
>>>
>>> Christoph Heindl wrote:
>>>>
>>>> On Wed, Apr 28, 2010 at 8:00 PM, Stewart, Robert
>>>> <Robert.Stewart_at_[hidden]> wrote:
>>>>
>>>>> At that point, I think they should be on par with any_cast
>>>>> rather than built on any_cast so that exceptions needn't be
>>>>> translated. Exception handling overhead is too costly to do
>>>>> it twice when it isn't necessary.
>>>>
>>>> I agree. I don't see any added value by using bad_get, except all
>>>> boost:get accessors would throw bad_get exceptions.
>>>
>>> Perhaps you missed my point. I was suggesting that your gets be
>>> implemented at the same level of access as any_cast so no exception
>>> translation were needed. In other words, take code straight from any_cast
>>> and use it to implement get, provided bad_cast is deemed useful.
>>
>> Indeed I did. In boost 1.42 this corresponds to duplicating ~40 lines
>> of code to exchange the type of exception thrown. I'm not too keen of
>> doing this (not talking about the tests I would have to duplicate too)
>> :) Of course, code could be refactored to refer to a common set of
>> methods that take the exception to throw as templated argument, if
>> desired.
>>
>> _______________________________________________
>> +1 for refactoring.
>> Best,
>> Vicente
>>
>>
>> _______________________________________________
>> Unsubscribe & other changes:
>> http://lists.boost.org/mailman/listinfo.cgi/boost
>>
> It would make little sense to have a boost::get working with both
> Boost.Variant and Boost.Any transparently if it does not have a consistent
> behavior (i.e. the same way of signaling a problem). I don't think
> refactoring some code to make the behavior consistent will be problematic.

Agreed.

> Currently, boost::bad_get is deriving directly from std::exception whereas
> boost::bad_any_cast is deriving from std::bad_cast. It might make more sense
> to have both boost::bad_get and boost::bad_any_cast derive from a common
> exception class type, such as boost::bad_cast (or maybe have boost::bad_get
> derive from std::bad_cast)

I'd prefer to have boost::bad_get derive from std::bad_cast since it
seems like a natural fit to me. However, I haven't taken other
implementations of boost::get<T> and their exception handling into
consideration where a bad_cast exception might not be appropriate
(because nothing is to be casted).

Thinking about this further, what about having a common exception for
all boost::get (note the missing template argument), called bad_get
that derives from std::exception. Additionally we add bad_get_cast as
a specialization (i.e. derived from bad_get) for boost::get<T> where T
correponds to either boost::any , boost::variant or any other T that
requires casting internally.

--Christoph