home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!dtix!darwin.sura.net!convex!constellation!munnari.oz.au!metro!extro.ucc.su.OZ.AU!maxtal
- From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
- Newsgroups: comp.lang.c++
- Subject: Re: Renew?
- Message-ID: <1992Jul30.165447.17724@ucc.su.OZ.AU>
- Date: 30 Jul 92 16:54:47 GMT
- References: <memo.547224@cix.compulink.co.uk> <23347@alice.att.com>
- Sender: news@ucc.su.OZ.AU
- Organization: MAXTAL P/L C/- University Computing Centre, Sydney
- Lines: 29
- Nntp-Posting-Host: extro.ucc.su.oz.au
-
- In article <23347@alice.att.com> ark@alice.UUCP () writes:
- >In article <memo.547224@cix.compulink.co.uk> vadim@cix.compulink.co.uk writes:
- >
- >> I agree, that a pointer to original object stored somewhere
- >> else creates a dangerous situation, but this is still true even if the
- >> 'operator renew' was built-in in the language. Renew and realloc should
- >> be always used with caution.
- >
- >If renew guarantees to the user that the copy constructor and
- >destructor will be called for each object moved, that greatly
- >ameliorates the situation. It is then sufficient for the user to
- >get those two functions right, or make them private (which would
- >prohibit renew on objects of that class).
-
- Surely it is sensible that if renew is declared by the user,
- that version of renew is used. Otherwise, renew is generated from the
- copy constructor and destructor declared by the user.
-
- If the user declares neither the copy constructor or destructor,
- then the generated renew need not correspond to physical
- calls to the compiler generated copy constructor and destructor,
- since in this case all three are generated by the compiler.
-
-
- --
- ;----------------------------------------------------------------------
- JOHN (MAX) SKALLER, maxtal@extro.ucc.su.oz.au
- Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
- ;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
-