NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/lang/cplus/13039

Internet Message Format | 1992-08-29 | 2.3 KB

Path: sparky!uunet!portal!cup.portal.com!Aurelius
From: [e-mail] (Mark Christian Barnes)
Newsgroups: comp.lang.c++
Subject: Re: complex classes and temporary destruction.
Message-ID: <[e-mail]>
Date: Fri, 28 Aug 92 21:50:51 PDT
Organization: The Portal System (TM)
Distribution: world
References: <[e-mail]>
  <[e-mail]> <[e-mail]> <[e-mail]>
Lines: 49

Andrew Koenig writes:

|>  Have the temporary "inherit" (for lack of a better word) the
|> storage class of p. If p is an auto variable then 's+t' should
|> be auto too. Destroy p and 's+t' together. If p is static, then
|> perhaps have 's+t' be static as well, onc instance of 's+t'
|> gets re-used each time the statement is executed.
|
|I'm afraid that wouldn't work.  Consider this:
|
|char* I(char* x) { return x; }
|
|The function I (for identity) just returns its argument, but to make things
|difficult, it is compiled separately.  Now, you would like
|
|char* p = s+t;
|
|to cause the temporary for s+t to stick around as long as p does,
|but what are you going to do about this?
|
|        char* p = I(s+t);
|
|There's no way to know what I() does, so what basis do you have for
|letting the lifetime of p affect that of s+t?

 But Andrew, you have changed the statement completely. The
temporary 's+t' is no longer even being assigned to 'p'. It is
constructed as a parameter for function (or macro) 'I'. In this
case I would suggest that 's+t' is an auto variable with a scope
limited to 'I'.

 I know that this means that your example will not work under
this interpretation. Well I don't think it should. The perpetual
problem of aliasing, to which pointers contribute, should not be
solved by the compiler. I feel that the programmer should pay
attention to what he/she is doing.

 In your example, an expression is evaluated and passed
(on the stack) as the parameter to a function. The function
'I' returns another value of type pointer to char. There should
not be any assumption that the parameter and the return value
have anything in common. You, as the programmer, know that 'I'
returns the parameter. Therefore, you should also insure that
any parameters passed to 'I' are of the appropriate storage
class and scope for the uses that you intend.

<whew, that's enough for now.>

            Regards, [e-mail]