Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!decwrl!labrea!sri-unix!quintus!ok
From: ok@quintus.uucp (Richard A. O'Keefe)
Newsgroups: comp.lang.c++
Subject: Re: classes with no data members
Keywords: sizeof,empty classes,new
Message-ID: <139@quintus.UUCP>
Date: 25 Jun 88 03:26:18 GMT
References: <464@polari.UUCP> <7943@alice.UUCP> <470@polari.UUCP> <10399@sol.ARPA> <18223@cornell.UUCP> <423@bloom.UUCP> <5103@ihlpf.ATT.COM>
Sender: news@quintus.UUCP
Reply-To: ok@quintus.UUCP (Richard A. O'Keefe)
Organization: Quintus Computer Systems, Inc.
Lines: 18

In article <5103@ihlpf.ATT.COM> nevin1@ihlpf.UUCP (00704a-Liber,N.J.) writes:
>Unless someone can produce some evidence to the contrary, it seems to me
>that there is no purpose to taking the address of an empty object.

There are programming languages (SETL springs to mind) which have an
"atom" data type, the objects of which have *no* properties other than
their identities.  (Don't confuse them with Lisp atoms.)  I have also
seen this sort of thing used in VDM work.  I think that it would be
occasionally useful to have (typed) objects consuming no (real) store
-- type checking should ensure that pointers to null objects are not
compared with pointers to non-null objects, unless the programmer goes
out of his way to shoot himself in the foot -- which have no properties
other than identity, so that one doesn't absent-mindedly slide into
using arithmetic properties.  Using 'new' to generate a null object in
order to obtain a new token seems a lot cleaner to me than incrementing
a global integer variable, even if that's the implementation.

I would almost go so far as to say that the only reason for having empty
objects at all would be to to take their "addresses".