🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

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

Re: The realloc question: rationale?

#3513
From: Joe Buck
Date: Mon, 26 Feb 1996 20:13
59 lines
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!clamage
References: <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