Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!nbires!isis!ico!cadnetix.UUCP!gad
From: gad@cadnetix.UUCP (Gordon Durand)
Newsgroups: comp.lang.c++
Subject: Re: constructors and instantiation
Message-ID: <960@cadnetix.UUCP>
Date: Fri, 16-Oct-87 19:54:29 EDT
Article-I.D.: cadnetix.960
Posted: Fri Oct 16 19:54:29 1987
Date-Received: Sun, 18-Oct-87 23:21:15 EDT
References: <2575@sigi.Colorado.EDU>
Reply-To: gad@cadnetix.UUCP (Gordon Durand)
Distribution: na
Organization: Cadnetix Corp., Boulder, CO
Lines: 84

In article <2575@sigi.Colorado.EDU> chase@boulder.Colorado.EDU (Chase Turner) writes:
>...[ Example which has trouble with a user-defined storage allocator
>...  called from a constructor.]
>I am re-submitting the question to determine the following:
>

As something of a C++ novice myself, I may be completely off-base, but
I'll give it a try anyway...

>a) am I violating the sprit of instantiation?
>
	
It seems to me that the basic idea is ok, but there are two problems
in the sample sources:
	1. The object "ts" is allocated on the stack rather than via
	   a "new()" operator.
	2. The constructor references a member before assigning a value
	   to "this".
Both of these are verbotten according to 8.5.8.

>b) I want to instantiate objects in shared memory which is accessable to 
>seperate processes (environment : sun workstations, 4.3 unix) -- I do not want
>a function call *new* which provides an object space in local memory which
>would then have to be copied to a shared memory area.  (and, the local memory 
>reference would have to be deleted since I do not want the object there....) 
>Is the constructor the appropiate mechanism?
>

I believe that a constructor is the appropriate mechanism here.  I fixed
the two problems and your code acted just as one would hope.

>c)  why is the value of *this* not updated in the main body to reflect the
>assignment of the object to the malloc space I created?
>

The constructor modifies the local copy of "this" and returns that value
as the value of the function.  If a stamp object were being allocated via
"new()", then this value would be assigned to the stamp* and life would
be wonderful.  However, since "ts" is allocated on the stack, the return
value from the constructor is ignored, and the original address of "ts"
is passed to "print_myself()" as "this".  The relevant code fragments
from cfront are:

    struct stamp *_stamp__ctor (_au0_this , _au0_v )
    struct stamp *_au0_this ;
    int _au0_v ;
    { 
	// NOTE: bad assignment "val = v" removed.
	//
	// As per 5.5.7, constructor should guarantee that it
	// is called as a result of "new()".  The C++ code is:
	// if (this != 0) {
	//	printf ("Constructor not called via new() operator!!\n");
	//	/* fail miserably */
	// }
	_au0_this = (((struct stamp *)malloc ( (unsigned int )(sizeof (struct stamp ))) ));
	_au0_this -> _stamp_val = (_au0_v + 1 );
	_stamp_print_myself ( _au0_this ) ;
	return _au0_this ;
    }


    int main (){ _main(); 
    { 
	// Good usage via new(), the constructor return value is used.
	//
	struct stamp *_au1_ts ;
	_au1_ts = (struct stamp *)_stamp__ctor ( (struct stamp *)0 , 10 ) ;
	_stamp_print_myself ( _au1_ts ) ;

	// Bad usage without new.  The constructor return value is ignored
	// and the malloc'd space heads for oblivion.
	struct stamp _au1_oldts ;
	_stamp__ctor ( & _au1_oldts, 5 ) ;
	_stamp_print_myself ( & _au1_oldts ) ;
}


Hopefully I'm not too far off the mark with this response.
-- 
    Gordon Durand	UUCP: cadnetix!gad
    Cadnetix Corp.	      hao!ico!cadnetix!gad
    5757 Central Ave.
    Boulder, CO 80301