On 3 November 2010 11:21, Hossein Haeri
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