From:	Weiqi Gao <weiqigao AT a DOT crl DOT com>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: no copy-ctor for temps
Date:	Thu, 07 Oct 1999 00:05:30 -0500
Organization:	CRL Network Services
Lines:	23
Message-ID:	<37FC2A1A.90EA29A@a.crl.com>
References:	<37F562D4 DOT 57291365 AT a DOT crl DOT com> <eb8J3.1214$%K6 DOT 36 AT firefly> <aoUK3.214$_9 DOT 60 AT firefly>
NNTP-Posting-Host:	a116018.stl1.as.crl.com
Mime-Version:	1.0
X-Mailer:	Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i586)
X-Accept-Language:	en
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

"Wendy E. McCaughrin" wrote:
> 
> In a previous article, weiqigao AT a DOT crl DOT com (Weiqi Gao) says:
> 
> >>    TstCpy(Overflow(" I am a temporary\n"));  // passing temp: no
> >>                                              // copy-ctor
> >
> >The object is constructed on TstCpy()'s stack.
> 
> Well ... not exactly :)  I single-stepped through the disassembled
> code via FSDB and found that the object is ctor'd on main's stack,
> not on TstCpy's. The argument passed to TstCpy() is always a ptr to
> the temp, in both calls: that ptr is an address in main's stack-frame.

You are right.  Running it inside gdb reveals that the object is
constructed inside what gdb described as main's frame.  I guess that's
dictated by the calling convention.  But logically, the object lives
with TstCpy().  For example, it is destructed when TstCpy() returns. 
Also, only TstCpy() can access the object, while main() cannot.

-- 
Weiqi Gao
weiqigao AT a DOT crl DOT com

- Raw text -