Boost logo

Boost :

From: Stewart, Robert (stewart_at_[hidden])
Date: 2002-03-06 16:31:31

From: rwgk [mailto:rwgk_at_[hidden]]
> --- In boost_at_y..., "Stewart, Robert" <stewart_at_s...> wrote:
> > > Unfortunately the reserve() solution eventually requires
> > > use of push_back(), which is also slow.
> >
> > If you use push_back() following reserve(), there is no performance
> penalty.
> > The push_back()'ed object is copied into the next element. If you
> exceed
> > the size allocated with reserve(), then push_back() will cause
> reallocation
> > and copying, so be sure to choose the right size when calling
> reserve().
> Here is an example push_back() implementation:
> void push_back(const ElementType& x) {
> if (size() < capacity()) {
> new (end()) ElementType(x);
> m_incr_size(1);
> }
> else {
> m_insert_overflow(end(), size_type(1), x, true);
> }
> }
> I doubt that the optimizer can entirely remove the
> overhead associated with incrementing the size,
> and it can certainly not remove the "if" statement.

The memory for the vector is not reallocated, and the elements are not
copied from the old to a new allocation. That is, with a judicious call to
reserve() before push_back(), size() < capacity() will always be true, so x
will be copied into the uninitialized memory at end() and the size will be
incremented. Thus, there is no memory/copy performance penalty which is
what I thought "slow" was meant to imply. If a comparison of two integers
and the increment of another is more overhead than you can bear -- though it
certainly doesn't justify the label "slow"! -- then you need a fixed-size
array such as a C array or a wrapper class of a C array.

Susquehanna International Group, LLP

Boost list run by bdawes at, gregod at, cpdaniel at, john at