cornet@duteca (Jan-Pieter Cornet) (04/27/91)
When using a predefined class or classes that somehow act like an
arithmetic type, there are a number of occasions where a (temporary)
variable is first copied and immediately afterwards deleted. An example
is the return of such a type from a function.
If the defined class has a pointer member, the data pointed to by this
member will have to be copied, as the destructor will most probably
release the allocated memory.
This seems to me like a waste, as it would be better to just make the new
variable use the old data and not free this data at all. But a copy
constructor or assignment operator cannot, in the current language
definition, guess that the next operation on its argument will be delete,
and thus use the above suggested method of 'moving' instead of 'copying'.
So I want to propose a new prototype for both the assignment operator and
the copy constructor that _will_ be able to make use of the fact its
argument is about to be deleted (the new functions will have to do any
deletions explicitly, though)
The prototypes (for a general class X;) are:
X::X(delete X&); // construct a new X and delete the argument
~~~~~~
X& X::operator=(delete X&); // copy to *this and delete the argument
~~~~~~
These functions will provide the interface to the programmer whenever a
copy-with-delete is needed. The constructor will then be called whenever
the function return value is used as a temporary in further calculations;
the assignment operator is used in case the value returned is assigned to
an already-allocated variable.
Making these functions default to the obvious combination of the original
function and delete, no existing code is broken so compatibility is
guaranteed.
Note that the functionality suggested above can already be implemented
with the current definition of C++, by using reference counts and
copy-on-write schemes, as most memory managers work after the unix fork(2)
system call. But this solution seems to me like a hack and still clumsy
because the compiler can provide a better solution in this case.
I haven't spent much time thinking about implementation details but to me
it doesn't seem more difficult than the existing functionality.
I've submitted an article to comp.lang.c++ about this (called "Returning
class containing pointer members") but got no reactions on it. This
article describes an example class where the above functions would come in
quite handy.
I'd like to hear from you what you think of this idea, so maybe it can be
posted as a proposal to the C++ standards commitee.
-- Jan-Pieter Cornet
cornet@duteca.et.tudelft.nl
Student at the Delft University of Technology,
Dep. of Electrotechnical engineering.