Re: EBCO - why does it require inheritance?
Chris Fairles <chris.fairles@gmail.com> wrote in
news:1187697876.277189.261540@a39g2000hsc.googlegroups.com:
I think it has to do with subobjects having unique addresses.
Let's
change your example to
struct A {
SomeEmptyType t1;
SomeEmptyType t2;
int *1;
}
Then if we create an object a of type A, we would have to have
&a.t1
!= &a.t2, and similarly with member-pointers.
Joe Gottman
Ok, but if SomeEmptyType has no state, can you think of a use-case
that requires t1 and t2 to have unique addresses? Otherwise isn't
accessing t1 functionally equivolent to accessing t2 (and
substitutable in all cases?).
I can see if you were using the address of the object as its state,
then yes, they have to be unqiue but I can't think of a case where I'd
need that behavior.
Well, if SomeEmptyType is stateless and isn't some abstract base class,
then it is best spelled 'namespace' in my opinion. Then you aren't
creating an object for no purpose.
Creating objects is the crux of your problem. When you declare a t1 and
a t2, you are declaring to separate object instances. These instances
have the same value, but are not the same object. In normal object-
oriented terms, you would say that they didn't have the same object
identity. That is, if I declared two ints i and j. I assigned both of
them the value 1. We would then say that i == j, but we would not say
that i and j were the same int. Same thing here. We declared t1 and
t2. We might possibly say that t1 == t2 (because they were both empty)
but we would not say that t1 and t2 were the same object. Clear so far?
In C++ object identity is determined by its address. Therefore if t1
and t2 were to maintain separate identities &t1 != &t2. This is a
fundamental property of object oriented programming and not lightly
broken especially if there is so easy a way to get what you want without
breaking it.
So, we change the code to:
namespace SomeEmptyType
{
void f();
}
struct A {
int *i;
}
using namespace SomeEmptyType;
f();
-or-
class SomeEmptyType
{
public:
static void f();
};
struct A {
int *i;
}
SomeEmptyType::f();
and we are in the same boat as before. There is nothing to be gained in
accessing f() via an instance of A, so why tie them together?
joe