Re: [Boost-users] [Any] Operator ==

Subject: Re: [Boost-users] [Any] Operator ==
From: Nevin Liber (nevin_at_[hidden])
Date: 2010-11-03 14:50:09

On 3 November 2010 11:21, Hossein Haeri <powerprogman_at_[hidden]> wrote:
> Dear Nevin,
>
>> > In case you're wondering why I'd interested in such
>> operators, the answer is that I'm thinking of storing
>> objects of type boost::any in an unordered_map.
>>
>> Wouldn't this just be the address of the object (which
>> isn't
>> particularly useable as a key in a map)?
>
> So, what specifically is undesirable in Boost.Any for storing their addresses in containers?

Storing its address, sure.  Using that address as a key (which is the
address of its location in the map)?  How do you envision using that?
Why would you need Boost.Any as the key type in that case?  If this is
really the functionality you need, maybe consider using a
shared_ptr<void> instead.

It certainly isn't something I'd like to see in Boost.Any, as that
isn't usually what people mean by equality comparable.  Take the
following example given the semantics you propose:

boost::any x(0);
boost::any y(x);

assert(x == y);   // fails

One that forwards the work to (lhs == rhs) for the underlying objects
is much more interesting, but would require extending Boost.Any to
implement it.  It also means defining semantics for:

1.  What to do if they hold the same type
2.  What to do if they hold different types
3.  What to do if one side is not a Boost.Any object
4.  What to do if operator== isn't defined for the types involved

My armchair answers:
1. Forward to the expression lhs == rhs for the held objects
2. Forward to the expression lhs == rhs for the held objects
3. Compile time error
4. Throw

I can, however, see arguments for other semantics for some of these cases.
-- 
 Nevin ":-)" Liber  <mailto:nevin_at_[hidden]>  [phone]