Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (JAMES ADCOCK)
Newsgroups: comp.lang.c++
Subject: Re: warning message from Sun C++ 2.0
Message-ID: <10028@microsoft.UUCP>
Date: 21 Dec 89 17:39:00 GMT
References: <1286@sunquest.UUCP> <10264@alice.UUCP>
Reply-To: jimad@microsoft.UUCP (JAMES ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 41

In article <10264@alice.UUCP> ark@alice.UUCP (Andrew Koenig) writes:
>one of two reasons:
>
>	(1) they want to be able to modify the argument.
>
>	(2) they want to avoid copying the argument for efficiency
>	    and do not intend to modify it.
>
>If you're using a reference for reason (1), it's bad news for
>you to pass a temporary, because anything you change will be
>discarded with the temporary.  Thus the warning, which future
>releases will make into an error.

Hm, I can see where this might deserve a warning, but there would
seem to be many situations where you want to modify a temporary.
One [weak] example is that tired old warhorse complex number dimorph
re/im or mag/pha.  The temp gets added to something so its changes itself
from mag/pha to re/im.  Its not "constant" [or is it?  -- I disagree with
people who believe "const" should not imply constant structure] so you
[or at least I] wouldn't want to declare it constant.  But then "future
releases" would mark this an error.

Perhaps a better example would be say a linked string class where op+
causes a temporary structure of linked strings to be built up --
the links are temporaries that must be modified to add more strings to
the linked list.  But the linked string representation is itself temporary --
eventually the linked list of strings is flattened to a linear string,
and the temporary links are discarded.  Why should this approach deserve
to be called an "error?"

In general, marking temps that change as "errors" would seem to make temps
second class citizens, and force classes to be coded to correctly handle
both cases: 1) objects that can change, and 2) those who can't.  On the
other hand, maybe ark can argue that temps are now considered to be
of flavor "const" and the new restrictions on temps are to be considered
a requirement to make all our classes work right in both the "const" and
"non-const" cases?  But there would seem to be reasonable, every day class
designs where it just doesn't make sense to consider any members of that
class "const."

Any Thoughts?