home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!snorkelwacker.mit.edu!thunder.mcrcim.mcgill.edu!sobeco!philmtl!vedge!hendrik
- From: hendrik@vedge.UUCP (Hendrik Boom)
- Newsgroups: comp.lang.c++
- Subject: Re: destruction of temporaries
- Message-ID: <28619@vedge.UUCP>
- Date: 26 Aug 92 13:42:47 GMT
- References: <TMB.92Aug21160625@arolla.idiap.ch>
- Organization: Visual Edge Software, St. Laurent, Quebec
- Lines: 44
-
- tmb@arolla.idiap.ch (Thomas M. Breuel) writes:
- :
- : Under either rule, expressions can already be rewritten to obtain the
- : desired lifetime. For example:
- :
- : X result = x.a().b().c().d();
- :
- : Language: early destruction, Wanted: late destruction:
- :
- : X a = x.a();
- : X b = a.b();
- : X c = b.c();
- : X result = c.d();
- :
- : Language: late destruction, Wanted: early destruction:
- :
- : X a = x.a();
- : X b = a.b();
- : destroy(a);
- : X c = b.c();
- : destroy(b);
- : X result = c.d();
- : destroy(c);
- :
- What is 'destroy'? Some language feature I don't know about that
- isn't in the ARM syntax? Or a user-defined member funtion that has
- no control over the calling of the actual destructors of members
- of a, b, and c?
-
- : The question is: what should be the default. I don't think that
- : mandatory late destruction solves anything, because if you start
- : relying on the persistence of temporaries in expressions, the next
- : step is that you'll get confused about why they don't hang around for
- : the whole block.
-
- And you have to worry about a destroy function that can't actually
- destroy very much.
- :
- : Thomas.
- --
- -------------------------------------------------------
- Try one or more of the following addresses to reply.
- at work: hendrik@vedge.com, iros1!vedge!hendrik
- at home: uunet!altitude!ozrout!topoi!hendrik
-