ctor.txt

来自「开放源码的编译器open watcom 1.6.0版的源代码」· 文本 代码 · 共 83 行

From x3j16=[e-mail] Tue May 21 18:07:17 1991
Received: from att.att.com by watmsg.waterloo.edu with SMTP
	id <AA21055>; Tue, 21 May 91 18:07:08 EDT
From: x3j16=[e-mail]
Original-From: bartok!att!uunet.uu.net!microsoft!martino
Errors-To: [e-mail]
Reply-To: [e-mail]
Received: by att.att.com; Tue May 21 15:34:54 EDT 1991
Received: from microsoft.UUCP (LOCALHOST.UU.NET) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA04707; Tue, 21 May 91 15:34:38 -0400
Original-From: microsoft![e-mail]
Message-Id: <[e-mail]>
To: uunet!bartok.att.com!redbone![e-mail]
Subject: Temporaries and Base/Member Initialisers
Date: Tue May 21 12:06:45 1991
Status: R

To: X3J16 core language mailing list
Message x3j16-core-621

One of the issues still on my plate, is resolving what to do when the
initialiser for a base or member requires the generation of a temporary.

Consider :-

	class Nasty
	{
	private:
		const int & ri;
	public:
		Nasty ( float f )  : ri ( f )  {}  // Temp. required
		Nasty ( int & rj ) : ri ( rj ) {}  // No temp required
	};

	Nasty * foo ( float ff )
	{
		// Where can the temp go ????
		Nasty * pNasty = new Nasty ( ff );

		return pNasty;
	}

	Nasty * bar ( float ff )
	{
		int i = ff;

		// Same thing, but programmers problem
		Nasty * pNasty = new Nasty ( i );

		return pNasty;
	}

The specification does not make this illegal, yet, I do not know where to
put the required temporary.  If the constructor is in a separate translation
unit, I do not even have the luxury of knowing that the temporary is required.

On my implementation, and that of other vendors who handle this construct,
the temporary is unfortunately created on the stack of the constructor
function (where else ?), and of course, this is not persistant, so an error
occurs due to a transient temporary being bound to a more persistant object.

The problem gets worse, when instead of an 'int' a type with a destructor
is involved, because its destructor is invoked at the end of the constructors
execution, since it is a local temporary.

My feeling is that such constructs should be outlawed by the language
definition.  It is simple to detect the requirement for the persistant
temporary, and to generate an error message.

A statement in the language definition like :-

       "A const reference member of a class must be initialised with an
	addressable expression of the exact type of the reference member."

or some such wording should correct the problem, without bringing up the
thorny implementation problem of required temporaries.


	Martin