search

blueszhangsh / gperftools

Automatically exported from code.google.com/p/gperftools
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

realloc not very usable in C++ #141

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
The following is a feature request for tcmalloc . If accepted, I'm happy to 
help work on it, and 
expand on it.

realloc is not really usable in C++, as many C++ objects can't be moved with a 
memcpy. 
Therefore it would be really nice to have a method that looked something like:

int try_realloc(int* data, int new_size)

Which would try to expand data to new_size, and return the largest it could 
make the block 
without actually causing movement.

This looks to me to be a fairly small code change, and would add a very useful 
function. It would 
however break compatibility with other mallocs, and require including a special 
header from 
tcmalloc.

Original issue reported on code.google.com by 4zuma...@gmail.com on 9 Jun 2009 at 2:37

GoogleCodeExporter commented 9 years ago 
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 csilv...@gmail.com on 9 Jun 2009 at 5:56

GoogleCodeExporter commented 9 years ago 
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 4zuma...@gmail.com on 10 Jun 2009 at 3:32

GoogleCodeExporter commented 9 years ago 
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 csilv...@gmail.com on 2 Aug 2010 at 4:51

GoogleCodeExporter commented 9 years ago 
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 csilv...@gmail.com on 31 Aug 2011 at 10:14