Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!lll-winken!aunro!alberta!cpsc.ucalgary.ca!news
From: gintera@cpsc.ucalgary.ca (Andrew Ginter)
Newsgroups: comp.lang.c++
Subject: Re: Overloaded operator dot
Message-ID: <1991Jun10.215544.24406@cpsc.ucalgary.ca>
Date: 10 Jun 91 21:55:44 GMT
References: <41694@ucbvax.BERKELEY.EDU> <5175@lupine.NCD.COM> <1991May27.233113.14550@hal.com>
Sender: gintera@cpsc.ucalgary.ca
Organization: U. of Calgary Computer Science
Lines: 39

In article <1991May27.233113.14550@hal.com> shap@hal.com (Jonathan Shapiro) writes:
>As one of the people who helped cause operator-> to come into
>existance, I want to draw out some problems of understanding in the
>operator-> exchange that I have seen.
 ...
>The problem with answer (1) lies in the undefined lifespan of the
>temporary object.  One of the important uses of operator arrow and
>operator * is in supporting pseudo-garbage-collection and locking
>primatives.  Look at what happens in the code:
>
>	c = a->b;
>	f(c);
>
>In proposal 1, the compiler is free to generate 
>
>	tmp = (*a)
>	c = tmp.b;
>	destroy(tmp)
>	f(c);
>
>This would break an operator * based locking scheme.

Look at what happens with existing support for the "->" operator:

	c = (a()) -> b;
	f (c);

Compilers are currently free to generate:

	tmp = a();
	c = tmp -> b;
	destroy(tmp);
	f(c);

This breaks an operator-> based locking scheme.  As one of the people
who helped cause operator-> to come into existance, can you tell us if
this problem was discussed at all?  How should it be dealt with?

Andrew Ginter, 403-220-6320, gintera@cpsc.ucalgary.ca