Luis Coelho <deepblack@geocities.com> wrote:
>Why doesn't the standard allocator interface include a reallocate
>function ...?  After some thought I think the best might be to
>have reallocate return bool :
>reallocate returns true if it succeeds in getting more memory in
>the same place (no copy of old elements necessary). Otherwise it
>does nothing and return false. ...
>
>Didn't anyone propose this for the standard, wasn't it approved?

This is a good question.
It is a good idea, and should have been considered, but wasn't.

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Luis Coelho wrote in message <372f0104.5911556@news.uni-weimar.de>...

>Why doesn't the standard allocator interface include a reallocate
>function with similar functionallity to C's realloc?

Perhaps because the containers do this automatically.

>For example:
>
><code>
>vector<int> v(1000);
>v.resize(v.capacity());
>v.push_back(1);
></code>
>
>The last line will certainly have the vector reallocate memory
>and copy at least 100 ints to a new location.

Using the most maligned C++ compiler around, I recently wrote code that
creates large vectors of ints by doing _only_ push_backs. Feeling guilty
about this clearly and blatantly inefficient implementation, I rewrote the
routines using pre-allocated C-style arrays and found that there was
essentially _no_ difference in performance. (Although writing the code was
much harder, even though the algorithms had at that point been designed and
tested.) Copying ints (or pointers) is no big deal, but obviously copying
objects that have nontrivial copy constructors is.

> If you had a
>reallocate method in vector there would be the possibility of
>getting some memory after the one existing therefore avoiding the
>copying of elements.


Right, that's why the standard containers already do this.
Since the best strategy for extending a vector will vary with the
application (presumably), maybe
some sort of access to the reallocation strategy might be somewhat useful,
but right now empirical tests indicate that the standard library does an
awfully good job.

The implementation I'm using apparently doubles the capacity when
push_back() exceeds current capacity. This means that whereas creating and
then populating a vector with n elements invokes the copy constructor n
times, creating an n-element vector by iterated push_back() will invoke the
copy constructor 2*n times.

David J. Littleboy
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

This is not a 'why isn't there a realloc in C++' which is
answered by 'use vector<T>'. My question is

Why doesn't the standard allocator interface include a reallocate
function with similar functionallity to C's realloc?

For example:

<code>
vector<int> v(1000);
v.resize(v.capavity());
v.push_back(1);
</code>

The last line will certainly have the vector reallocate memory
and copy at least 100 ints to a new location. If you had a
reallocate method in vector there would be the possibility of
getting some memory after the one existing therefore avoiding the
copying of elements.

The only problem I see is how to define the interface and
semantics of the function. After some thought I think the best
might be to

Have reallocate return bool

reallocate returns true if it succeeds in getting more memory in
the same place (no copy of old elements necessary). Otherwise it
does nothing and return false.

vector<T>::reserve(size_type n) might then be implemented as

if (alloc.reallocate(data,n))
{
 m_capacity = n;
}
else
// ... allocate new memory, copy elements, free old memory


Another major possibility is to

Have it work like C's realloc

C uses bitwise copy which is inapropriate, but one might get
around this by making reallocate internally use construct to copy
elements. The main problem however is that not all of the
existing memory might need to be moved (the memory might not be
all used). reallocate would need a parameter telling it howmany
objects, if any, to move (if necessary).

(for an allocator type named A:)

A::pointer A::reallocate(A::pointer old, A::size_type
requested_elems, A::size_type elems_to_move);

Didn't anyone propose this for the standard, wasn't it approved?
Just a questiong I've been thinking about.
Luis Coelho.
C++ Programming Language, 3rd Ed. by B. Stroustrup. My exercise answers at:
http://www.geocities.com/SiliconValley/Way/3972/index.html


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]