Topic: Proposal about lifetimes of objects
Author: pat@bnrmtl.bnr.ca (Patrick Smith)
Date: 15 Aug 91 16:03:23 GMT Raw View
I'd like to make a suggestion for a small language extension
which might help compilers to deal appropriately with the
lifetimes of objects (especially temporaries). I haven't seen
it discussed before; my apologies to everyone if there has been
such a discussion and I missed it.
The proposal is to allow a programmer to state, in the declaration
of a function, that the result of the function depends on one
or more parameters of the function. That is, after the function
is called, the parameter(s) should not be destroyed until after
the result has been destroyed.
There is more than one way to do this. The one I like best
(so far) is to use the keyword static when declaring the parameters,
as in:
class A;
class B;
A f( static B b );
A g( static A a2, static A a2, A a3, B b );
class X
{
X( static A a );
X( A a, static B b );
operator char*() static; // result depends on *this
};
The principal effect of this would be to improve the handling
of temporaries. Consider
class string
{
char* P;
public:
string( const char* p ) { P = strdup(p); }
~string() { free(P); }
string operator+( const char* p ); // concatenation
operator const char*() static;
};
// ...
void f( const char* );
string s = "abc";
f( s + "def" );
This code would be safe under the proposal, since the compiler
would know that the temporary string representing s+"def" should not
be destroyed until after f returns (because the const char* argument
to f is only destroyed after f returns).
Another effect is that questionable code such as
const char* f()
{
string s( "abc" );
return s;
}
can be either prohibited or flagged with a warning by the compiler.
My preference would be that the language allow such code, but
good compilers issue warning messages.
A few closing notes:
First, as the ARM points out, a compiler with access to all of the
source code could, in theory, deduce whether it is safe to destroy
the arguments of a function before destroying the result.
But I imagine that this would be extremely difficult, especially
since it depends not only on what the function does, but how
the result of a particular call is used.
Second, I don't like adding yet another meaning to the word
static. But this seems better than adding a new keyword just
for this minor feature. Is there a better alternative?
Third, if this were restricted to constructors and conversion
operators, then another syntax suggests itself: placing a
keyword (I'd suggest volatile here) in the declaration as if
it were a return type:
class A;
class X
{
volatile X( A a, B b ); // result depends on a AND b
volatile operator char*();
};
Fourth, this proposal doesn't allow the programmer to do anything
that couldn't be done without it. What it does do is make some
code (using temporaries) perform as expected, instead of producing
random results. It also allows the compiler to warn the programmer
about some types of questionable code.
Well, that's it. Any comments? Flames?
--
Patrick Smith Bell-Northern Research, Montreal, Canada
(514) 765-7914 bnrmtl!pat@larry.mcrcim.mcgill.edu patrick@bnr.ca
... Any resemblance between the above views and those of my employer,
my terminal, or the view out my window are purely coincidental.