Re: std::complex design (Was: N-Dimensional array lib rary submission...)

From: rwgk (rwgk_at_[hidden])
Date: 2002-03-06 17:50:50

--- In boost_at_y..., "Stewart, Robert" <stewart_at_s...> wrote:
> From: rwgk [mailto:rwgk_at_y...]
> > 
> > --- 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.

I agree that the overhead for std::vector will probably not be
noticeable in most applications and on most CPUs. But sometimes
people mention that an if-statement inside a loop causes
certain CPU-specific optimizations/advantages to break down.
I.e., the performance degrades disproportionally. I am not
sure how true this still is for modern CPUs.

The other point is that the code above is from a reference
counted container implementation. size(), capacity() and end()
look up member data of a separate object (the handle that
maintains the reference count and the memory). In this
situation you really have to think twice before using
push_back().

Back to the original question of changing the default
constructor of std::complex (to not initialize the
data members): this would mean that, e.g.:

std::complex<double>()

behaves differently than

double()

B. Stroustrup writes (section 6.2.8 of The C++ Prog. Lang.):

"The value of an explicit use of the constructor for a
built-in type is 0 converted to that type."

IMO std::complex<double>() and double() should behave
the same way.

Back to the question of initializing vectors of
std::complex: IMO the relevant container types
(vector, valarray, anything else?) should provide
a facility (constructor) to set the size() without
initializing the values if possible, i.e. if the
value_type has a trivial destructor (this is more general
than the requirement that the value_type is a POD
type). A couple of hours ago I posted a suggestion
for this that has unfortunately not yet shown up...
(but see the recent replies from David under the same
subject).

Ralf