Boost logo

Boost :

Subject: Re: [boost] [any] boost::get style accessors
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-04-30 06:57:45


Christoph Heindl wrote:
> On Thu, Apr 29, 2010 at 7:26 PM, vicente.botet
> <vicente.botet_at_[hidden]> wrote:
> >
> > Thinking a little bit more the introduction of boost::get<>
> > in Boost.Any would result at the end on the deprecation of
> > any_cast, isn't it?
>
> If boost any_cast<> has equivalent sematics to boost::get<> and
> boost::get<> is the perferred generic way (which I think it is) to
> retrieve values then +1 for the deprecation.

+1 for having a common approach to extracting such values. boost::get<> is consistent with tuples, not just variant, so I think it is the right interface. any_cast is, of course, highly specific.

I don't know that any_cast need be deprecated, though, because I haven't looked into the details. If it works differently in any way, can be more efficient, or is otherwise a closer fit to boost::any, then there's no reason to deprecate or remove it. Those working strictly with boost::any could prefer it. If those things are not true, then I think deprecation is in order.

> > So the refactoring at the interface level will introduce
> > constraints that sould be avoided.
>
> Could you please elaborate on your thoughts?

I suppose that Vicente meant that this would be a breaking change that he'd like to avoid, which is understandable. I don't think maintaining both interfaces and explaining why both exist is onerous, so that might be the best course.

_____
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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk