🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.std.c++
Article #3276

proposal: renew & relocator member fn

#3276
From: Gregory Bond
Date: Wed, 07 Feb 1996 03:25
88 lines
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!austern

Show 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