chase@boulder.Colorado.EDU (Chase Turner) (10/15/87)
This message was submitted two weeks ago; there have not been any replies yet.
I am re-submitting the question to determine the following:
a) am I violating the sprit of instantiation?
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?
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?
Any reply would be appreciated. Thanks in advance. Chase.
---------old message below------------------------------
I am having difficulty utilizing the Free Store example (8.5.8, pg 280
of The C++ Programming Language). Specifically, I need to instantiate
objects within shared memory; for the purposes of this example, I will
utilize a malloc instead of the call shmget ().
Within the constructor, I re-assign the value of "this"
but the update value is ignored. In fact, I assumed that the constructor
would over-ride the instantiation of the object "ts" in the main body,
but the c code generated by the CC pre-compilier indicates that a local
structure is created prior to the call to the constructor.
The following is a run-time example.....
value is 11, address is 142912 // within the constructor
value is 10, address is 251657776 // after returning from constructor
The following is the program......
#include <stream.h>
#include <libc.h>
#include <syscall.h>
class stamp {
int val;
public:
stamp (int);
void print_myself ();
};
stamp::stamp (int v)
{
val = v; //val should not exist since I have not made a call
//to new or reserved the space for the object.
//obviously it does exist. Is there an implicit
//call to new? Should I override new with another
//function? How can new be 'intercepted'?
this = (stamp*) malloc (sizeof (stamp));
val = v+1;
print_myself ();
}
void stamp::print_myself ()
{
printf(" value is %d, address is %d \n",val,&val);
}
main()
{
stamp ts (10);
ts.print_myself ();
}kens@hpldola.HP.COM (Ken Shrum) (10/16/87)
> I am having difficulty utilizing the Free Store example (8.5.8, pg 280 > of The C++ Programming Language). ... > ... > stamp::stamp (int v) { val = v; //val should not exist since I have not made a call //to new or reserved the space for the object. //obviously it does exist. Is there an implicit //call to new? Should I override new with another //function? How can new be 'intercepted'? In <The Book>, pg 280 it states explicitly that you must assign to this before any use of member if you wish to override the default action. On pg 164 it is made explicit that any use of a member before such an assignment is undefined. Regarding the other problem, you've allocated a stamp on the stack by writing: stamp foo(10); I believe that assigning a new value to this for objects on the stack is an undefined operation. See pg 163, 164. If you use stamp *foo = new stamp(10); you'll get the behavior you want. Ken Shrum hplabs!hpldola!kens
gad@cadnetix.UUCP (Gordon Durand) (10/17/87)
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
chip@ateng.UUCP (Chip Salzenberg) (10/20/87)
In article <2575@sigi.Colorado.EDU> chase@boulder.Colorado.EDU (Chase Turner) writes: >b) I want to instantiate objects in shared memory which is accessable to >seperate processes No problem. >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? Because the value of "this" is only modifiable for dynamically allocated objects. The "new" operator automatically invokes the appropriate constructor, so given the constructor you posted, you're in like a porch climber. (Except for the first assignment to val, which is a nono.) >main() >{ > stamp ts (10); > ts.print_myself (); >} This should be main() { stamp *ts = new stamp(10); ts->print_myself(); delete ts; } -- Chip Salzenberg "chip@ateng.UUCP" or "{uunet,usfvax2}!ateng!chip" A.T. Engineering My employer's opinions are not mine, but these are. "Gentlemen, your work today has been outstanding. I intend to recommend you all for promotion -- in whatever fleet we end up serving." - JTK