From -8388801204342498248
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f78e5,f5d433881cc29cff
X-Google-Attributes: gidf78e5,public
From: bparker@gil.com.au (Brian Parker)
Subject: Re: Named return value optimisation- reprise.
Date: 1997/06/19
Message-ID: <33a7217a.2219489@news.ipswich.gil.com.au>#1/1
X-Deja-AN: 250997141
References: <33a345bf.7425526@news.ipswich.gil.com.au> <33A478C1.329@acm.org> <33a4e2d5.24720499@news.ipswich.gil.com.au> <33A54D26.F46@acm.org> <5o3v6c$cv3@mulga.cs.mu.OZ.AU> <33A5A723.E9F@acm.org> <5o5mgd$mkv@mulga.cs.mu.OZ.AU> <33A6A1F9.D0E@acm.org>
X-Original-Date: Wed, 18 Jun 1997 00:21:41 GMT
Organization: Global Info-Links News Server
X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBFAgUBM6iVJ+EDnX0m9pzZAQFTPAGAnjN5kt2gCZoNPv56vIzQGxWZ3rOIXott yDGOo2IdWbOAZV5U7ZwzhuqRpHZPw/gH =3B8H
Newsgroups: comp.std.c++
Originator: fjh@mundook.cs.mu.OZ.AU


On 17 Jun 1997 09:25:34 PDT, Pete Becker <petebecker@acm.org> wrote:
 >
 >> OK, so where did I go wrong?
 >> 
 >
 >	You know, after I posted this I realized it was too clever. Making
 >destructor_count a global variable makes it clearer. I'm pretty sure
 >that I think static data is not part of an object, but that's an
 >unnecessary complication here.

Actually, in my original MV++ example, the shared data *is* global
data- it becomes a "part" of the vector on initialisation, but its
lifetime extends beyond the lifetime of the vector itself.

 >	The real point of all this is this:
 >
 >class C1
 >{
 >public:
 >	C() {}
 >	void set_data( int i ) { data[0] = i; }
 >	int get_data() const { return data[0]; }
 >private:
 >	int data[1];
 >};
 >
 >class C2
 >{
 >public:
 >	C() : data(new int) {}
 >	// suitable assignment operator and copy constructor, of course...
 >	~C2() { delete data; }
 >
 >	void set_data( int i ) { data[0] = i; }
 >	int get_data() const { return data[0]; }
 >private:
 >	int *data;
 >};
 >
 >	I don't see any fundamental difference between these two classes,
 >merely a difference in implementation. A definition of "object" that
 >says they have different properties is wrong. Internally they are
 >somewhat different, but from the outside they present exactly the same
 >interface and exactly the same states and behaviors.
 >	-- Pete

I agree 100%, a standard that treated these two classes differently
would simply be wrong- and hence the language would not be useful for
any critical application. The trouble is that not everyone shares that
view and would be willing to accept the bugs 12.8/15 introduces- and
hence take the literal meaning of "object" in 12.8/15 i.e. only the
memory created on initial definition.

The problem with rewording 12.8/15 to use the definition of "object"
that includes all memory used indirectly is that it is not
well-defined. The example above is clear, but when the various bits of
memory used by an object are shared and/or have different lifetimes
(and particularly when you add you add garbage-collection to this mix)
then it is not clear when a bit of memory is a "part" of the object
and when it is simply being temporarily used.
And if 12.8/15 does not have a precise definition of object, then it
would always leave open the possibility of a bug-introducing loophole,
and so one would always need to code defensively anyway.

A standard need to define precise semantics- I think it would be a
grave mistake to leave 12.8/15 in the draft as is.

,Brian Parker (bparker@gil.com.au)
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]