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.