26 Jul, 2009, Silenus wrote in the 1st comment:
Votes: 0
I have been trying to implement the notion of equality for a object hierarchy in order to do comparisons between different objects in the hierarchy which may include comparing subclasses to subclasses. The only methods I can think of (for doing this) is to use type codes or RTTI- both of which I am trying to avoid. Is there some sort of idiomatic third way to accomplish this(or am I dreaming)?

Thanks in advance.
26 Jul, 2009, Lobotomy wrote in the 2nd comment:
Votes: 0
Language?

Edit: Meh.
26 Jul, 2009, David Haley wrote in the 3rd comment:
Votes: 0
It's C/C++ – check the forum section.

And yes, Silenus, I think you are dreaming. :wink: If you don't know the object's type, how do you expect to test equality? Note that it is probably somewhat unusual for objects of different types to be equal.

But really, how do you expect to avoid type codes or RTTI while trying to figure out an object's type at runtime?

If all of your objects exposed the same interface that gave you everything that needed to be tested, I suppose you'd be ok. But this is a very unlikely scenario.
26 Jul, 2009, Tyche wrote in the 4th comment:
Votes: 0
Silenus said:
The only methods I can think of (for doing this) is to use type codes or RTTI- both of which I am trying to avoid. Is there some sort of idiomatic third way to accomplish this(or am I dreaming)?


There is an idiomatic third way
to test objects for their equivalence.
Compare pointers to the objects themself.
26 Jul, 2009, Silenus wrote in the 5th comment:
Votes: 0
Generalizing a bit I assume you could do this with multi-methods? My C++ skills are still somewhat newbie but in theory can you not do some form of double dispatch? Admittedly this implementation is probably worse than using type codes or RTTI since you have to spill function definitions for the dispatching everywhere(in C++ anyhow).
26 Jul, 2009, quixadhal wrote in the 6th comment:
Votes: 0
I guess the question is, how "equal" is "equal"?

If I create two objects of class foo, they could be considered equal with respect to both being the same type of object, but their values may be totally different. In some cases, it may not even be possible to have their values be 100% identical. What if the class has a method that returns a random number (based off a seed value stored in the class itself, not in each instance)? If the class reflects hardware registers (keypress data, serial port states, you name it), two objects might well be 100% equal, but unless you can lock their state for the duration of the comparison, they won't LOOK equal.

So, do you really mean "equal", or do you mean "is-a"? In that case the question becomes "are these two objects instances of the same class?" or "is x a foo?" I don't know enough C++ to know the answer to that one. It seems like the object should have some kind of reference to its class, but since C++ isn't dynamic the compiler may throw all that away as "meta-data" you don't need.
26 Jul, 2009, Silenus wrote in the 7th comment:
Votes: 0
Well the problem can be resolved using RTTI i.e. where you can ask questions whether like whether x is an instance of the concrete class y. Probably I can even get the behavior I want using double dispatch though the function spew in C++ makes this option not particulary appetizing. Obviously if C++ supported multimethods like CLOS or a language like Cecil the dispatch mechanism could in principle resolve this issue for me as well- I was basically wondering if there was some "trick" I had not considered.

In this case I am basically interested in some sort of deep value equivalence. Basically I hope to apply it to two difference cases:

1) One is a form of equality which I hope to intertwine with an index. i.e. lookup if the value entity in question is in an index and if so return some absolute numeric tag which indicates it's value. I am a bit concerned whith memory usage here though I suspect if you shared values it might not be so bad (though this might make the initial lookups and assignment a bit more tricky).

2) Unification.

Currently I am opting for a type code solution though there are a few details I still need to figure out. Thanks everyone for the input.
0.0/7