I wrote:

...

...

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)?

OvermindDL1 wrote:

Actually it would be possible.  For example, Adobe's Any version has a streaming operator (which throws I think if the stored type does not support streaming, or just does not accept it, one or the other).

Would you mind providing a link to that please?

  The way it does it can easily be extended to handle a == of the internal value (not just the type) as well.

Actually, I found out that I can store addresses of objects of type any in a set and get my desired functionality. But, I would still need to implement a wrapper around Boost.Any.

Hmm, perhaps it is time for an extended Boost.Any that supports 'concepts' of a sort of the stored types.  Hmm, Boost.Proto could probably simplify the scaffolding a lot as well...

In fact, I'm in need of that for a maniac idea to be used by my Proto components. So, I would be interested to hear more about this if you don't mind. TTFN, --Hossein

On 3 November 2010 11:21, Hossein Haeri 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@eviloverlord.com  (847) 691-1404

On 3 November 2010 14:39, Thorsten Ottosen wrote:

Den 03-11-2010 19:50, Nevin Liber skrev:

...

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

2. return false?

That is a possibility. So is throwing or asserting. Giving it slightly more thought, I don't believe you can solve #2 with the answer I proposed, since you need to have the expression "lhs == rhs" somewhere in the source for any two arbitrary types. If a goal is to be able to use the object as a key in an associative container, returning false is probably the best bet. Of course, operator== is not sufficient to use the object as a key in a [unordered_][multi](set|map). You need hashability for the unordered_ case and operator< to implement a strict weak ordering for the other case. The OP did have a SWO but it wasn't very useful (in my opinion). One we could implement is to first order based on typeid(T).before() and a secondary ordering based on std::less or the expression lhs < rhs. --  Nevin ":-)" Liber  mailto:nevin@eviloverlord.com  (847) 691-1404