realloc not very usable in C++
GoogleCodeExporter opened this issue · comments
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
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
- Added labels: Priority-Low, Type-Enhancement
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
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
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
- Changed state: WontFix