I noticed that boost::any does not have an operator== for comparing two boost::any objects. Is this a deliberate choice? Currently I have to (1) compare the types, and (2) convert the values with any_cast (and probably catch bad_any_cast exceptions) and compare them.
On 01/14/2014 12:42 PM, Bjorn Reese wrote:
I noticed that boost::any does not have an operator== for comparing two boost::any objects. Is this a deliberate choice?
Currently I have to (1) compare the types, and (2) convert the values with any_cast (and probably catch bad_any_cast exceptions) and compare them.
And which type do I use for any_cast?
AMDG On 01/14/2014 05:41 AM, Bjorn Reese wrote:
On 01/14/2014 12:42 PM, Bjorn Reese wrote:
I noticed that boost::any does not have an operator== for comparing two boost::any objects. Is this a deliberate choice?
Currently I have to (1) compare the types, and (2) convert the values with any_cast (and probably catch bad_any_cast exceptions) and compare them.
And which type do I use for any_cast?
You can't determine the correct type automatically. This is exactly why any doesn't support operator==. In Christ, Steven Watanabe
2014/1/14 Bjorn Reese
On 01/14/2014 12:42 PM, Bjorn Reese wrote:
I noticed that boost::any does not have an operator== for comparing two boost::any objects. Is this a deliberate choice?
Currently I have to (1) compare the types, and (2) convert the values with any_cast (and probably catch bad_any_cast exceptions) and compare them.
And which type do I use for any_cast?
Short answer to your problems: use Boost.TypeErasure library. It'll help you to make your own boost::any with blackjack and comparison operators. Long answer to the issues with boost::any and operator==: It is possible to add such operator, but that will require change of internal structures and * increase requirements for all stored type (they all must be comparable) => breaks existing user code OR * make runtime errors in cases when TypeErasure library give compile time errors => making runtime errors from compile time is not a C++ way -- Best regards, Antony Polukhin
participants (4)
-
Antony Polukhin
-
Bjorn Reese
-
Steven Watanabe
-
Thorsten Ottosen