From: wemccaug AT prairienet DOT org (Wendy E. McCaughrin) Newsgroups: comp.os.msdos.djgpp Subject: Re: no copy-ctor for temps References: <37FC2A1A DOT 90EA29A AT a DOT crl DOT com> <37F562D4 DOT 57291365 AT a DOT crl DOT com> Lines: 39 Message-ID: Date: Thu, 14 Oct 1999 22:33:03 GMT NNTP-Posting-Host: 192.17.3.4 X-Complaints-To: newsmgr AT prairienet DOT org X-Trace: firefly 939940383 192.17.3.4 (Thu, 14 Oct 1999 17:33:03 CDT) NNTP-Posting-Date: Thu, 14 Oct 1999 17:33:03 CDT Organization: Prairienet -- Your Community Network for East Central Illinois To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com In a previous article, weiqigao AT a DOT crl DOT com (Weiqi Gao) says: >"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 > I should have read the info on options more carefully. Apparently, the default action of `gpp' is _not_ to invoke the copy ctor in my circum- stance (to init a temp), and this seems to be in accordance with the current C++ standard. If one _always_ wants the copy ctor invoked, just specify option: -fno-elide-constructors. Thanks for all the help! -- Wendy