TITLE: Follow up to: Are object addresses unique identifiers?

PROBLEM: jamshid@ses.com (Jamshid Afshar)

[ last part of previous tip repeated... -adc ]

How could this cause a problem in real code?  Say the B constructor
stores `this' in a static Set<B*> to keep track of all "live" B
objects.  If B::~B() removes `this' from the set, we would get an
error when d2 is destroyed because the destructors for both d2 and
d2.d1 would try to remove the same B* address from the set.


RESPONSE: tob@world.std.com (Tom O Breton)

I do not believe the language should be guarding against such a remote
special case. It should simply not guarantee pointer uniqueness for
empty classes. In the very, very, very rare case where you want to use
an empty class in that manner, add a dummy variable. (Frankly, I suspect
there are zero real cases of empty class + virtual functions + want to
hold all the virtuality data elsewhere.)


RESPONSE: jamshid@ses.com (Jamshid Afshar)

I don't think such cases are very rare.  It's not uncommon to have a
class derived from a purely abstract class use a sibling concrete
class in its implementation.  For example:

	template<class T>
	class Container {   // abstract class and no data members
	public:
	   virtual T get() = 0;
	   //...
	};

	template<class T>
	class List : public Container<T> {     // concrete class
	   //...
	public:
	   virtual void insert(T t, ListIter<T> pos) {/*...*/}
	   //...
	};

	template<class T>
	class PriorityQueue : public Container<T> {  // concrete class
	   List<T> d;
	public:
	   virtual T get() { return d.first(); }
	   //...
	};

I simply don't think &pq should be allowed to be equal to &pq.d.  I
think the compiler, not the programmer, should add a dummy data member
or rearrange the object layout to ensure this doesn't happen *when
necessary*.  It's not at all difficult for the compiler to determine
when such overhead is necessary (eg, it would not be necessary in this
example under all C++ compilers I know of).  The compiler can
certainly make this decision much more easily and efficiently than a
programmer.