[any] boost::get style accessors
Hi all, I couldn't find any boost::get<T> style accessors for boost::any, so I came up with an implementation that looks something along the following lines. #include <boost/any.hpp> #include <boost/call_traits.hpp> namespace boost { template<class T> typename boost::call_traits<T>::reference get(any &a) { return boost::any_cast<typename boost::call_traits<T>::reference>(a); } template<class T> typename boost::call_traits<T>::const_reference get(const any &a) { return boost::any_cast<typename boost::call_traits<T>::const_reference>(a); } } In case it cannot be converted to the desired destination type a bad_any_cast exception is thrown. The above code enables boost.any and boost.variant to be used interchangeably as far as boost::get<T> is concerned. Any thoughts? Best regards, Christoph
----- Original Message ----- From: "Christoph Heindl" <christoph.heindl@gmail.com> To: <boost@lists.boost.org> Sent: Tuesday, April 27, 2010 7:15 PM Subject: [boost] [any] boost::get style accessors
Hi all,
I couldn't find any boost::get<T> style accessors for boost::any, so I came up with an implementation that looks something along the following lines.
<snip>
In case it cannot be converted to the desired destination type a bad_any_cast exception is thrown.
The above code enables boost.any and boost.variant to be used interchangeably as far as boost::get<T> is concerned.
Any thoughts?
Doesn't any_cast do what you are looking for? template<typename T> T any_cast(any &); template<typename T> T any_cast(const any &); template<typename ValueType> const ValueType * any_cast(const any *); template<typename ValueType> ValueType * any_cast(any *); Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/
vicente,
Doesn't any_cast do what you are looking for? template<typename T> T any_cast(any &); template<typename T> T any_cast(const any &); template<typename ValueType> const ValueType * any_cast(const any *); template<typename ValueType> ValueType * any_cast(any *);
sure thing. If you look closely, any_cast is called from within my code. However, when trying to using boost::any and boost::variant interchangeably it is handy to have a common interface like the one boost::get provides. Christoph
Christoph Heindl wrote:
Hi all,
I couldn't find any boost::get<T> style accessors for boost::any, so I came up with an implementation that looks something along the following lines.
#include <boost/any.hpp> #include <boost/call_traits.hpp>
namespace boost {
template<class T> typename boost::call_traits<T>::reference get(any &a) { return boost::any_cast<typename boost::call_traits<T>::reference>(a); }
template<class T> typename boost::call_traits<T>::const_reference get(const any &a) { return boost::any_cast<typename boost::call_traits<T>::const_reference>(a); } }
In case it cannot be converted to the desired destination type a bad_any_cast exception is thrown.
The above code enables boost.any and boost.variant to be used interchangeably as far as boost::get<T> is concerned.
Any thoughts?
Best regards, Christoph _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
You may want to extend this by adding support for get(any*) and get(any const*). Also, for making them usable interchangeably via boost::get, you need them to throw the same exception. Therefore, in case you are using boost::any, you probably want to rethrow bad_any_cast to bad_get. namespace boost { template<class T> typename boost::call_traits<T>::reference get(any &a) { try { return boost::any_cast<typename boost::call_traits<T>::reference>(a); } catch (boost::bad_any_cast const &) { throw(boost::bad_get()); } } template<class T> typename boost::call_traits<T>::const_reference get(const any &a) { try { return boost::any_cast<typename boost::call_traits<T>::const_reference>(a); } catch (boost::bad_any_cast const &) { throw(boost::bad_get()); } } template <class T> T* get (any *a) { return boost::any_cast<T>(a); } template <class T> T const* get (const any *a) { return boost::any_cast<T>(a); } } Yours, Stefan P.S. While looking through [1] I noticed that boost::bad_get is missing a nothrow virtual dtor: virtual ~bad_get() throw() { } Unless I'm wrong, someone should probably add that there.
Stefan wrote:
Christoph Heindl wrote:
Hi all,
I couldn't find any boost::get<T> style accessors for boost::any, so I came up with an implementation that looks something along the following lines.
#include <boost/any.hpp> #include <boost/call_traits.hpp>
namespace boost {
template<class T> typename boost::call_traits<T>::reference get(any &a) { return boost::any_cast<typename boost::call_traits<T>::reference>(a); }
template<class T> typename boost::call_traits<T>::const_reference get(const any &a) { return boost::any_cast<typename boost::call_traits<T>::const_reference>(a); } }
In case it cannot be converted to the desired destination type a bad_any_cast exception is thrown.
The above code enables boost.any and boost.variant to be used interchangeably as far as boost::get<T> is concerned.
Any thoughts?
Best regards, Christoph _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
You may want to extend this by adding support for get(any*) and get(any const*). Also, for making them usable interchangeably via boost::get, you need them to throw the same exception. Therefore, in case you are using boost::any, you probably want to rethrow bad_any_cast to bad_get.
namespace boost { template<class T> typename boost::call_traits<T>::reference get(any &a) { try { return boost::any_cast<typename boost::call_traits<T>::reference>(a); } catch (boost::bad_any_cast const &) { throw(boost::bad_get()); } }
template<class T> typename boost::call_traits<T>::const_reference get(const any &a) { try { return boost::any_cast<typename boost::call_traits<T>::const_reference>(a); } catch (boost::bad_any_cast const &) { throw(boost::bad_get()); } }
template <class T> T* get (any *a) { return boost::any_cast<T>(a); }
template <class T> T const* get (const any *a) { return boost::any_cast<T>(a); } }
Yours, Stefan
P.S. While looking through [1] I noticed that boost::bad_get is missing a nothrow virtual dtor: virtual ~bad_get() throw() { } Unless I'm wrong, someone should probably add that there.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Sorry, [1] = http://www.boost.org/doc/libs/1_42_0/boost/variant/get.hpp Stefan
Stefan wrote:
Stefan wrote:
Christoph Heindl wrote:
I couldn't find any boost::get<T> style accessors for boost::any, so I
[snip]
Also, for making them usable interchangeably via boost::get, you need them to throw the same exception. Therefore, in case you are using boost::any, you probably want to rethrow bad_any_cast to bad_get.
namespace boost { template<class T> typename boost::call_traits<T>::reference get(any &a) { try { return boost::any_cast<typename boost::call_traits<T>::reference>(a); } catch (boost::bad_any_cast const &) { throw(boost::bad_get()); } }
template<class T> typename boost::call_traits<T>::const_reference get(const any &a) { try { return boost::any_cast<typename boost::call_traits<T>::const_reference>(a); } catch (boost::bad_any_cast const &) { throw(boost::bad_get()); } }
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. _____ Rob Stewart robert.stewart@sig.com 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.
On Wed, Apr 28, 2010 at 8:00 PM, Stewart, Robert <Robert.Stewart@sig.com> 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. -- Christoph
Christoph Heindl wrote:
On Wed, Apr 28, 2010 at 8:00 PM, Stewart, Robert <Robert.Stewart@sig.com> 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@sig.com 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.
On Thu, Apr 29, 2010 at 1:10 PM, Stewart, Robert <Robert.Stewart@sig.com> wrote:
Christoph Heindl wrote:
On Wed, Apr 28, 2010 at 8:00 PM, Stewart, Robert <Robert.Stewart@sig.com> 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. Best Regards, Christoph
----- Original Message ----- From: "Christoph Heindl" <christoph.heindl@gmail.com> To: <boost@lists.boost.org> 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@sig.com> wrote:
Christoph Heindl wrote:
On Wed, Apr 28, 2010 at 8:00 PM, Stewart, Robert <Robert.Stewart@sig.com> 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
vicente.botet wrote:
----- Original Message ----- From: "Christoph Heindl" <christoph.heindl@gmail.com> To: <boost@lists.boost.org> 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@sig.com> wrote:
Christoph Heindl wrote:
On Wed, Apr 28, 2010 at 8:00 PM, Stewart, Robert <Robert.Stewart@sig.com> 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. 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) Yours, Stefan
----- Original Message ----- From: "Stefan" <mstefanro@gmail.com> To: <boost@lists.boost.org> Sent: Thursday, April 29, 2010 6:50 PM Subject: Re: [boost] [any] boost::get style accessors
vicente.botet wrote:
----- Original Message ----- From: "Christoph Heindl" <christoph.heindl@gmail.com> To: <boost@lists.boost.org> 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@sig.com> wrote:
Christoph Heindl wrote:
On Wed, Apr 28, 2010 at 8:00 PM, Stewart, Robert <Robert.Stewart@sig.com> 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.
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. 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 was talking only on refactoring the code on Boost.Any for the functions get and any_cast ;-) 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? So the refactoring at the interface level will introduce constraints that sould be avoided. Best, Vicente Vicente
On Thu, Apr 29, 2010 at 7:26 PM, vicente.botet <vicente.botet@wanadoo.fr> 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.
So the refactoring at the interface level will introduce constraints that sould be avoided.
Could you please elaborate on your thoughts? -- Christoph
Christoph Heindl wrote:
On Thu, Apr 29, 2010 at 7:26 PM, vicente.botet <vicente.botet@wanadoo.fr> 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@sig.com 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.
----- Original Message ----- From: "Stewart, Robert" <Robert.Stewart@sig.com> To: <boost@lists.boost.org> Sent: Friday, April 30, 2010 12:57 PM Subject: Re: [boost] [any] boost::get style accessors
Christoph Heindl wrote:
On Thu, Apr 29, 2010 at 7:26 PM, vicente.botet <vicente.botet@wanadoo.fr> 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.
Well, tuples don't have the type as parameter, but the index or a tag. In addition tuples don't need exceptions as the access is checked at compile time. Even if the name is the same and the intentions is quite close, although different, the interface is clearly different, so there is no advange other than using the same name, i.e. no possibility for generic code using both.
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.
What a meant is that if any_cast is deprecated it is not worth to try to assocaite bag_get and bad_any_cast in any way. best, Vicente
vicente.botet wrote:
From: "Stewart, Robert" <Robert.Stewart@sig.com>
+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.
Well, tuples don't have the type as parameter, but the index or a tag.
Of course, but one still reaches for "boost::get<" to access the value with the suggested change, rather than something different for Boost.Any.
In addition tuples don't need exceptions as the access is checked at compile time. Even if the name is the same and the intentions is quite close, although different, the interface is clearly different, so there is no advange other than using the same name, i.e. no possibility for generic code using both.
There is an advantage, but not as much as between Boost.Variant and Boost.Any.
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.
What a meant is that if any_cast is deprecated it is not worth to try to assocaite bag_get and bad_any_cast in any way.
Yes, if you're willing to deprecate any_cast, then bad_any_cast can go with it. _____ Rob Stewart robert.stewart@sig.com 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.
On Fri, Apr 30, 2010 at 12:57 PM, Stewart, Robert <Robert.Stewart@sig.com> wrote:
+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.
What are the next logical steps? Should I come up with an initial implementation and post it as patch (against the trunk) to the mailing list, or should I remain silent until some decision is made by library maintainers, people on the mailing list or whoever is in charge. -- Christoph
Christoph Heindl wrote:
On Fri, Apr 30, 2010 at 12:57 PM, Stewart, Robert <Robert.Stewart@sig.com> wrote:
+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.
What are the next logical steps? Should I come up with an initial implementation and post it as patch (against the trunk) to the mailing list, or should I remain silent until some decision is made by library maintainers, people on the mailing list or whoever is in charge.
Submit a patch via Trac and mention the Trac ticket here. If the maintainer (Kevlin Henney) doesn't notice the ticket after a reasonable time, we can try other ways to get his attention. _____ Rob Stewart robert.stewart@sig.com 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.
On Thu, Apr 29, 2010 at 6:50 PM, Stefan <mstefanro@gmail.com> wrote:
vicente.botet wrote:
----- Original Message ----- From: "Christoph Heindl" <christoph.heindl@gmail.com> To: <boost@lists.boost.org> 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@sig.com> wrote:
Christoph Heindl wrote:
On Wed, Apr 28, 2010 at 8:00 PM, Stewart, Robert <Robert.Stewart@sig.com> 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
On Wed, Apr 28, 2010 at 7:21 PM, Stefan <mstefanro@gmail.com> wrote:
You may want to extend this by adding support for get(any*) and get(any const*).
Good catch.
Also, for making them usable interchangeably via boost::get, you need them to throw the same exception. Therefore, in case you are using boost::any, you probably want to rethrow bad_any_cast to bad_get.
Is bad_get used by any other boost::get than the one of boost::variant? If not, I think sticking to the libraries 'native' exceptions is OK. Is there any interest in adding this to boost.any? From the boost documenation page it seems that Kevlin Henney is the maintainer. Should I contact him personally or raise a trac ticket? Best regards, Christoph
participants (4)
-
Christoph Heindl -
Stefan -
Stewart, Robert -
vicente.botet