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".