Boost::any operator==
Hi It would be nice if operator== could be added to boost::any. A partial solution would be the following: template<typename ValueType> bool operator==(const ValueType & rhs) const { return content ? content->equal(any(rhs).content) : content == any(rhs).content; } bool operator==(const any &rhs) const { return content && rhs.content ? content->equal(rhs.content) : content == rhs.content; } equal is a pure virtual member of placeholder declared as: virtual bool equal(const placeholder *rhs) const = 0; and implemented as (in holder): virtual bool equal(const placeholder *rhs) const { return type() == rhs->type() && held == static_cast<const holder<ValueType>*>(rhs)->held; } However, this will break existing code when the holded object class does no have operator== defined. Kevlin Henney proposed: namespace equality { template<typename Type> bool operator==(const Type &lhs, const Type &rhs) { return &lhs == &rhs; } } virtual bool equal(const placeholder *rhs) const { using namespace equality; return type() == rhs->type() && held == static_cast<const holder<ValueType>*>(rhs)->held; } Thus providing a default operator== for everyone not having its own, which returns true if the object addresses are the same. This will prevent compiler errors when the operator== really needed to be there. What I think is needed is: 1. If operator== is not used there should be no need for holded classes to implement it. 2. If operator== is used, and the holded class does not define it, the code must not compile. Do you think this is possible to implement? Thanks in advance Jorge Lodos
Hi Jorge, I found some corner cases while trying to implement Kevlin's idea. If you're interested, I can send you my letter to Kevlin.
1. If operator== is not used there should be no need for holded classes to implement it. 2. If operator== is used, and the holded class does not define it, the code must not compile. It's not possible. You may create "any" object in one TU and call operator== in other. A compiler doesn't know about other TUs. It just compiles current TU.
-- Alexander Nasonov Project Manager http://www.akmosoft.com
I found some corner cases while trying to implement Kevlin's idea. If you're interested, I can send you my letter to Kevlin.
Thanks, I'm interested :-)
1. If operator== is not used there should be no need for holded classes to implement it. 2. If operator== is used, and the holded class does not define it, the code must not compile. It's not possible. You may create "any" object in one TU and call operator== in other. A compiler doesn't know about other TUs. It just compiles current TU.
Assuming the holded object class is the same (and does not have operator== in the interface), the behavior I want is that the TU not using any::operator== does compile, while the TU using it does not. The expected error would be operator== not defined for holded class. The conditions were meant for a single TU. This can be achieved with not instantiated templates, but not with boost::any which inherently needs run-time polimorphism :-( In other words, what I would like is to have different (compiler generated) boost::any classes. One without operator== in case it is not used. The other needs the holded class operator== implementation and won't compile without it.
-- Alexander Nasonov Project Manager http://www.akmosoft.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Cheers Jorge
Jorge Lodos wrote:
Hi It would be nice if operator== could be added to boost::any.
That does not make sense. The purpose of any is to be a generic holder for ANY type, which includes those that are not equality comparable. Thus, defining an operator == for any is counter-intuitive, and doesn't work properly anyway. The proposed solution below:
namespace equality { template<typename Type> bool operator==(const Type &lhs, const Type &rhs) { return &lhs == &rhs; } }
does not make sense because every any allocates its own inner object. In other words, the identity equality check of the held object is effectively an identity equality check of the any object itself. But aside from the implementation and semantic problem, the whole basic idea irritates me. What makes equality check special? Why not implement +, >, and all the other operators for any too? Let's never forget that equality is about value equality, not about identity. If you want identity, you should compare the addresses in the first place. The mixing of these two concepts is one of the things I dislike about Java and particularly C#. Sebastian Redl
Hi It would be nice if operator== could be added to boost::any.
That does not make sense. The purpose of any is to be a generic holder for ANY type, which includes those that are not equality comparable.
Yes, that's why I said the first solution (the one you did not include) was not satisfactory.
Thus, defining an operator == for any is counter-intuitive, and doesn't work properly anyway. The proposed solution below:
Why is it counter-intuitive? I expect that 2 anys are equal if the following conditions are both true: 1. The holded objects have operator== defined 2. The holded objects are equal.
and doesn't work properly anyway. The proposed solution below:
namespace equality { template<typename Type> bool operator==(const Type &lhs, const Type &rhs) { return &lhs == &rhs; } }
does not make sense because every any allocates its own inner object. In other words, the identity equality check of the held object is effectively an identity equality check of the any object itself.
Only if the operator== is not defined for holded object. I would not say the solution does not make sense, but I don't think this is what is needed. Note this is not my solution. Allthough I like the trick proposed there and I'm sure it can be used in other more suitable places, the credit is not mine.
But aside from the implementation and semantic problem, the whole basic idea irritates me. What makes equality check special? Why not implement +, >, and all the other operators for any too? Let's never forget that
Why not? As long as: 1. The operator has meaning for holded objects. 2. The operation can be performed between holded objects 3. The code won't compile if some not defined (by holded objects) operator is used. I'm not talking here about feasibility, but as the "whole basic idea". Sorry this causes you irritation.
equality is about value equality, not about identity. If you want identity, you should compare the addresses in the first place. The mixing of these two concepts is one of the things I dislike about Java and particularly C#.
What I want is equality.
Sebastian Redl _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Jorge Lodos
Jorge Lodos wrote:
Why not? As long as: 1. The operator has meaning for holded objects. 2. The operation can be performed between holded objects 3. The code won't compile if some not defined (by holded objects) operator is used.
But this #3 is exactly why it can't work. Any doesn't know at compile time which type it might hold. Not even at link time, or even run time. Any any object may be passed in from a different compilation unit, a shared library even, one that's dynamically loaded to satisfy my run time claim. You can perhaps do this with variant, but not with any. I also think that this is simply a misuse of any. It's not supposed to be worked with. It's intended for user-supplied data carried along by a library, like for example the user data in the DOM. (In DOM Level 3, every DOM node has a string->any map of user data. The DOMUserData type maps to Object in Java, no type in particular in ECMAScript, and could conceivably map to boost::any in C++.) This data is only ever held by the library in its any container. Every access to the data should be performed by any-casting it back to its original type, which the client should know. (In the case of DOM, the data is associated with string keys, so ideally, every string key would always have data of the same type.) If use of any is restricted to this case, no comparison of anys is ever necessary. Sebastian Redl
FWIW, the Adobe Source Libraries solved this problem by implementing adobe::value_t, a cousin of boost::any that models the RegularType concept, and so requires operator== for any type it holds. <http://opensource.adobe.com/classadobe_1_1value__t.html> Blessings, Foster -- Foster T. Brereton - Computer Scientist Software Technology Lab, Adobe Systems Incorporated fbrereto@adobe.com -- http://opensource.adobe.com
Am Dienstag, den 18.04.2006, 14:12 -0700 schrieb Foster Brereton:
FWIW, the Adobe Source Libraries solved this problem by implementing adobe::value_t, a cousin of boost::any that models the RegularType concept, and so requires operator== for any type it holds.
As you shamelessly pointed to your own, non-boost class, I hope I may do that, too :-). I wrote a class much like any which uses traits to determine whether an action is supported and if not, an exception is thrown at run-time. Its documentation and implementation might be poor but it's pretty nice to be able to dump your Xany - that's the classes name - values right on std::cerr. You can find the code here: http://gott.snip-a-lot.de/snapshots/ondemand/net.sourceforge.gott/gott/xany/
Blessings, Foster
Thank you, Aristid, who is a hobbyist programmer and student PS: Feel free to comment about my classes, whether via private mail or if that's fine for the list via the list.
participants (5)
-
Alexander Nasonov -
Aristid Breitkreuz -
Foster Brereton -
Jorge Lodos -
Sebastian Redl