realloc not very usable in C++ about gperftools

[GoogleCodeExporter]

The problem I see is that, in c++, allocating memory isn't typically enough: 
you also
need to construct/initialize it.  I agree with you: I've wanted a realloc 
equivalent
for a while.  But I don't see a principled way to do it in C++.

One piece of evidence that this is hard is that the original SGI Allocator
implementation included a realloc function, but the one that eventually made it 
out
into the world doesn't:
   http://www.sgi.com/tech/stl/alloc.html
   http://www.sgi.com/tech/stl/Allocators.html

One interesting note from this discussion:

"This is probably the most questionable design decision. It would have probably 
been
a bit more useful to provide a version of reallocate that either changed the 
size of
the existing object without copying or returned NULL. This would have made it
directly useful for objects with copy constructors. It would also have avoided
unnecessary copying in cases in which the original object had not been 
completely
filled in."

This is exactly the function you're arguing for.  So perhaps it *would* be 
useful for
STL.  But with the standard Allocator type not supporting this kind of realloc, 
I'm
not sure how people could use it effectively in their c++ programs.  I guess it 
would
take a lot of work.

Anyway, I'll definitely take it under consideration.  I don't like extending the
tcmalloc API too much beyond the standard API, but I agree that this 
functionality is
helpful for c++.

Original comment by [email protected] on 9 Jun 2009 at 5:56

• Added labels: Priority-Low, Type-Enhancement

[GoogleCodeExporter]

I am currently working with a number of other people, trying to flesh out a 
good basis for this. There has been a 
number of previous proposals on this issue, and it would be nice to try to take 
the best ideas from all these 
suggestions.

Original comment by [email protected] on 10 Jun 2009 at 3:32

[GoogleCodeExporter]

Any more news on this?  We've introduced malloc_size(), which does something 
like what you want (it doesn't look for unallocated memory adjacent to existing 
memory, but it does indicate if the existing memory block is bigger than was 
asked for).  It may be the most practical solution.  If I don't hear back 
shortly, I'm going to close this WontFix (or maybe PartiallyFixed? :-) )

Original comment by [email protected] on 2 Aug 2010 at 4:51

[GoogleCodeExporter]

I guess I defined "shortly" to be "a year" in this case. :-)  I'm closing 
WontFix, though PartiallyFixed would be more accurate.

Original comment by [email protected] on 31 Aug 2011 at 10:14

• Changed state: WontFix