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

Subject: Re: [boost] [any] boost::get style accessors
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-04-29 07:10:25

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.

On the latter point, generic code can respond to any std::exception, but only in a generic way (sorry for the pun).  If generic code must account for a bad cast versus any other source of exception, however, then there must be a common exception type.  Whether bad_cast is the right type or there's another, better choice, depends upon whether there are other exceptions in use within Boost for that purpose.  If there are others, then a hierarchy must be introduced so the existing exceptions derive from a common base that is to be the official type for that purpose, or the existing types can be replaced with typedefs, so the one, official type can be used everywhere.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.