Article View: comp.std.c++
Article #3513Re: The realloc question: rationale?
From: Joe Buck
Date: Mon, 26 Feb 1996 20:13
Date: Mon, 26 Feb 1996 20:13
59 lines
3060 bytes
3060 bytes
I wrote: >> You can, of course, call the C realloc(). Kerry Kimbrough <kk@onr.com> writes: >But then crash? My understanding is that mixture of alloc/free and friends >with new/delete is not guaranteed to be valid and therefore is discouraged. >Not true? True. If you want to use the C realloc, you'll need to mix it with malloc and free. >If true, then realloc'ing a new'ed object ain't kosher, and there goes the >hope for specializing STL to implement realloc efficiently, i.e. w/o copy and >delete. That does not follow: my discussion of how to do the equivalent of realloc using template specialization does not use the realloc function at all. STL (at least in the HP implementation) does not use new directly to get memory; allocators get raw memory, and placement new is used to turn raw memory into objects. STL already has to have a realloc mechanism: when vectors and deques grow, they are reallocated and the older data is moved to fit into the newly allocated space. This is exactly what realloc does. So answer #1 to those who cry out for realloc is to say "Use the STL vector class: it looks like an array and does realloc for you". For arrays of T where T doesn't have a destructor, it's just the same. To reallocate a vector to have capacity n, you just say myVector.reserve(n); The HP implementation does the reallocation operation by calling uninitialized_copy (using the copy constructor and placement new to generate copies) followed by destroy (invoking the destructor on the original objects). This is inefficient for class objects that have lots of sub-objects on the heap, as a shallow copy would be a lot less work. My proposed modification is to replace the uninitialized_copy/destroy combination with a "relocate" template that, by default, does the same thing, but that can be specialized to move specific classes more efficiently. But all that does is make relocation work better; it's already there now. -- -- Joe Buck <jbuck@synopsys.com> (not speaking for Synopsys, Inc) Work for something because it is good, not just because it stands a chance to succeed. -- Vaclav Havel [ 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 ]
Technical Details
Message-ID:
<4gsupf$ovm@hermes.synopsys.com>Path:
arc1-ca.pugleaf.net!engnews1.Eng.Sun.COM!taumet!clamageReferences:
<4g903m$7g8@mari.onr.com> <4gl2ad$lqi@hermes.synopsys.com> <31301BFE.450A@onr.com>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!engnews1.Eng.Sun.COM!taumet!clamage From: jbuck@Synopsys.COM (Joe Buck) Newsgroups: comp.std.c++ Subject: Re: The realloc question: rationale? Date: 26 Feb 1996 20:13:36 GMT Organization: Synopsys Inc., Mountain View, CA 94043-4033 Approved: clamage@eng.sun.com (comp.std.c++) Message-ID: <4gsupf$ovm@hermes.synopsys.com> References: <4g903m$7g8@mari.onr.com> <4gl2ad$lqi@hermes.synopsys.com> <31301BFE.450A@onr.com> NNTP-Posting-Host: taumet.eng.sun.com X-Nntp-Posting-Host: deerslayer.synopsys.com Originator: clamage@taumet