Thread View: comp.std.c++
5 messages
5 total messages
Started by Gregory Bond
Wed, 07 Feb 1996 03:25
proposal: renew & relocator member fn
Author: 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. ]
Re: proposal: renew & relocator member fn
Author: john (j.d.) hickin
Date: Sat, 10 Feb 1996 08:35
Date: Sat, 10 Feb 1996 08:35
23 lines
1633 bytes
1633 bytes
|> Go ahead, shoot me down! POW! Seriously, how can the compiler tell when deep-copy is or isn't needed. You can help it, however, by using auto_ptr for the 'external' parts of an object (i.e., those logically part of it but included through a pointer; this term is my own so don't expect others to use it; I am looking for a better term). With auto_ptr's in place your relocate operation is a breeze -- just copy the object with a copy constructor and placement new. This seems to be an ideal application for certain semantics of auto_ptr that have been considered to be offensive. To be maximally const-correct your class will need a non-const copy constructor. -- John Hickin Nortel Technology, Montreal, Quebec (514) 765-7924 hickin@bnr.ca --- [ comp.std.c++ is moderated. Submission address: std-c++@ncar.ucar.edu. Contact address: std-c++-request@ncar.ucar.edu. Moderation policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]
Re: proposal: renew & relocator member fn
Author: devitto
Date: Tue, 20 Feb 1996 05:48
Date: Tue, 20 Feb 1996 05:48
24 lines
1924 bytes
1924 bytes
On 10 Feb 96 08:35:39 GMT, john (j.d.) hickin (hickin@bnr.ca) wrote:
: |> Go ahead, shoot me down!
: POW!
I 'wrote' with Bjarne about a general 'renew' a couple of years ago. u
Basically the problem is that a general "resize this C array" routine is
difficult without virtual contructors, and virtual copy constructors
- otherwise the routine would need static type binding (templates).
--
_____________________________________________________________________________
Dom De Vitto devitto@ferndown.ate.slb.com
Schlumberger Automatic Test Equipment fox@bcs.org.uk
Board Systems Desk/voicemail: +44(0) 1202 850951
Wimborne, Dorset, Site reception: +44(0) 1202 850850
England, BH21 7PP Fax: +44(0) 1202 850988
_____________________________________________________________________________
---
[ To submit articles: try just posting with your news-reader.
If that fails, use mailto:std-c++@ncar.ucar.edu
FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
Comments? mailto:std-c++-request@ncar.ucar.edu.
]
Re: proposal: renew & relocator member fn
Author: Tony Cook
Date: Tue, 20 Feb 1996 23:22
Date: Tue, 20 Feb 1996 23:22
30 lines
2047 bytes
2047 bytes
devitto@ferndown.ate.slb.com wrote:
: On 10 Feb 96 08:35:39 GMT, john (j.d.) hickin (hickin@bnr.ca) wrote:
: : |> Go ahead, shoot me down!
: : POW!
: I 'wrote' with Bjarne about a general 'renew' a couple of years ago. u
: Basically the problem is that a general "resize this C array" routine is
: difficult without virtual contructors, and virtual copy constructors
: - otherwise the routine would need static type binding (templates).
Urr...why?
Doesn't using delete [] on a pointer with the wrong static type
produce undefined behaviour anyway? ([expr.delete] stanza 3)
Actually, if we had a memory allocator that split what realloc does
into 'attempt to expand this block' and 'allocate a new block' then
we can write renew ourselves. Unfortunately, at least some,
operating systems, won't support this.
--
Tony Cook - tony@online.tmx.com.au
100237.3425@compuserve.com
---
[ To submit articles: Try just posting with your newsreader. If that fails,
use mailto:std-c++@ncar.ucar.edu
FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
Comments? mailto:std-c++-request@ncar.ucar.edu
]
Re: proposal: renew & relocator member fn
Author: Pablo Halpern
Date: Thu, 22 Feb 1996 15:51
Date: Thu, 22 Feb 1996 15:51
38 lines
2028 bytes
2028 bytes
jbuck@Synopsys.COM (Joe Buck) wrote:
> [Discussion about need for a special relocation constructor/destructor ]
>Consider the template
>
>template<class T>
>T* relocate(T* oldloc, void* newloc) {
> T* result = new(newloc) T(*oldloc);
> oldloc->~T();
>}
>
> [Discussion about how this template be specialized for classes where
relocation could be made cheaper]
>
I like this a lot. I wouldn't mind seeing this added to the standard
library and used in the implementation of STL.
It doesn't solve one problem that realloc() does solve: the ability to
prevent relocation if the allocator is able to grow a block without
relocating it. I believe run-time library support tied to a language
extension is needed if you are to take advantage of an operating-system
capability like that. We can probably live without such a language
extension.
-------------------------------------------------------------
Pablo Halpern phalpern@truffle.ultranet.com
I am self-employed. Therefore, my opinions *do* represent
those of my employer.
[ To submit articles: Try just posting with your newsreader.
If that fails, use mailto:std-c++@ncar.ucar.edu
FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
Comments? mailto:std-c++-request@ncar.ucar.edu
]
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads