Article View: comp.std.c++
Article #3276proposal: renew & relocator member fn
From: Gregory Bond
Date: Wed, 07 Feb 1996 03:25
Date: Wed, 07 Feb 1996 03:25
88 lines
4261 bytes
4261 bytes
[Yes, I know it's too late to consider new features. So consider this
advance notice for the next round!]
People often ask for a "renew[]" operator to complement "new[]" in the
same way realloc() complements malloc(). Of course the problem there
is contructing the new objects and destructing the old ones, so a
whole bunch of code gets written to do a new[], a bunch of assigns and a
delete[]. This (or the moral equivalent using malloc(), placement new
and delete) is especially prevalent inside container classes such
as STL.
I was thinking about the efficiency concerns here. For what is
conceptually a simple operation, three calls are made - a default
ctor, a copy ctor and a dtor. The copy ctor may potentially have to
allocate and deep-copy extensive data structures, so this can be very
expensive, especially when shallow copy would be sufficient if the
copy-ctor could KNOW that the source object was about to be destroyed.
So it seems to me that a combination of copy constructor and destructor
could be used in these circumstances to "relocate" an object. You
could call this special member a "relocator". This could offer
substantial efficiency gains, especially in situations like
vector<vector<A> >.
The first step would be to pick a syntax to specify the relocator.
This can't be an overloaded ctor (as any ctor arg list could
conceivably be a valid ctor). One posibility is to overload the dtor:
class A {
~A(); // destruct this
~A(A&to); // Contruct to and destruct this
// or perhaps ~A(void *to) as it will be passed an
// address of empty memory, not an object. But then
// you need to cast "to" to an "A*".
}
Another possibility is to hijack another character and use it for the
relocator in the same way ~ is used for the dtor. "@" seems somewhat
mnemonic for relocation but this introduces a new character into the
C++ character set. A third posability is to have a special member
function with an actual name (e.g. "relocator(A&)") but this is ugly.
The default relocator would be a copy ctor followed by a dtor.
One a relocator is defined, we could define renew[] (along with
operator renew[]):
X *p = new[10] X;
//...
renew[20](p); // 10 relocators and 10 def ctors called
// Or, if the existing memory block is big enough, the
// relocator isn't called at all, and 10 def ctors are called.
delete[] p;
Or, for situations such as the STL that manage raw memory via
placement-new and destructors:
X*p = (X*)malloc(10 * sizeof(X));
for (int i = 0; i < 10; i++)
new(p + i) X();
//...
X* new_p = (X*)realloc(p, 20 * sizeof(X));
if (new_p == p) {
// Was extended
for (int i = 10; i < 20; i++)
new (p + i) X();
} else {
// Was moved
// Note that realloc() has done a superfluous byte copy here
for (int i = 0; i < 10; i++)
(p+i)->~X(new_p + i);// relocate from p[i] to new_p[i]
for (int i = 10; i < 20; i++)
new (p + i) X();
free(p);
}
Has this sort of thing been considered before?
Go ahead, shoot me down!
Greg.
--
Gregory Bond <gnb@bby.com.au> Burdett Buckeridge & Young Ltd Melbourne Australia
``Efforts to maintain the "purity" of a language only succeed in establishing an
elite class of people who know the shibboleths. Ordinary folks know better,
even if they don't know what "shibboleth" means.'' - Larry Wall
---
[ comp.std.c++ is moderated. Submission address: std-c++@ncar.ucar.edu.
Contact address: std-c++-request@ncar.ucar.edu. The moderation policy is
in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]
Technical Details
Message-ID:
<GNB.96Feb7140952@dame.bby.com.au>Path:
arc1-ca.pugleaf.net!fido.asd.sgi.com!austernShow Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!fido.asd.sgi.com!austern From: gnb@bby.com.au (Gregory Bond) Newsgroups: comp.std.c++ Subject: proposal: renew & relocator member fn Date: 06 Feb 1996 19:25:03 PST Organization: Burdett, Buckeridge & Young Ltd., Melbourne, Australia Approved: austern@isolde.mti.sgi.com Message-ID: <GNB.96Feb7140952@dame.bby.com.au> NNTP-Posting-Host: isolde.mti.sgi.com X-Original-Date: 07 Feb 1996 03:09:52 GMT X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBVAwUBMRgbp0y4NqrwXLNJAQFPbwH8DLIpqRgAshMAcDv9fgjc69GfjXXOV+cG eaczUOjR2iL8AieFLvmYWXQ25Rf/RDTA7cuYMcyRTf6vLkfCc0z08A== =0CHE Originator: austern@isolde.mti.sgi.com