Initialization of vectors in c++

Discussion in 'C++' started by pauldepstein@att.net, Apr 13, 2008.

  1. Guest

    Experimenting at home with visual c++, I see that int main()
    {std::vector<double> vect(5);} creates a vector whose 5 initial
    values are all 0. Is this standard or might the five initial values
    be different from 0? I'm a bit surprised by this as I would expect
    vect to consist of five uninitialized doubles. Why is it that double
    x; introduces a double which is uninitialized and yet the above vect
    is initialized? Or is this just a matter of the definition of the c++
    language which should just be accepted, and can't be derived from some
    other principle?

    Thank you,

    Paul Epstein
     
    , Apr 13, 2008
    #1
    1. Advertising

  2. Barry Guest

    On Apr 13, 11:10 pm, wrote:
    > Experimenting at home with visual c++, I see that int main()
    > {std::vector<double> vect(5);} creates a vector whose 5 initial
    > values are all 0. Is this standard or might the five initial values
    > be different from 0? I'm a bit surprised by this as I would expect
    > vect to consist of five uninitialized doubles. Why is it that double
    > x; introduces a double which is uninitialized and yet the above vect
    > is initialized? Or is this just a matter of the definition of the c++
    > language which should just be accepted, and can't be derived from some
    > other principle?
    >


    Here you actually called

    explicit vector(size_type n, const T& value = T(),
    const Allocator& = Allocator());

    so the question becomes what T() equals to.

    8.5

    7
    An object whose initializer is an empty set of parentheses, i.e., (),
    shall be value-initialized.

    5
    To zero-initialize an object of type T means:
    -- if T is a scalar type (3.9), the object is set to the value of 0
    (zero) converted to T;
    ....

    To default-initialize an object of type T means:
    -- if T is a non-POD class type (clause 9), the default constructor for
    T is called
    (and the initialization is ill-formed if T has no accessible default
    constructor);
    -- if T is an array type, each element is default-initialized;
    -- otherwise, the object is zero-initialized.

    so with T==int, int() == 0
     
    Barry, Apr 13, 2008
    #2
    1. Advertising

  3. Jerry Coffin Guest

    In article <03277800-7557-456d-96b8-
    >, says...
    > Experimenting at home with visual c++, I see that int main()
    > {std::vector<double> vect(5);} creates a vector whose 5 initial
    > values are all 0. Is this standard or might the five initial values
    > be different from 0? I'm a bit surprised by this as I would expect
    > vect to consist of five uninitialized doubles. Why is it that double
    > x; introduces a double which is uninitialized and yet the above vect
    > is initialized? Or is this just a matter of the definition of the c++
    > language which should just be accepted, and can't be derived from some
    > other principle?


    As others have pointed out, the value is guaranteed to be zero.

    What they haven't pointed out (directly) is that you can specify another
    value if you prefer. E.g.:

    std::vector<double> vect(5, 15.0);

    --
    Later,
    Jerry.

    The universe is a figment of its own imagination.
     
    Jerry Coffin, Apr 13, 2008
    #3
  4. Jerry Coffin wrote:
    > As others have pointed out, the value is guaranteed to be zero.


    Sometimes I feel this is counter-productive speedwise.

    If I want to allocate a large array of, for example, integers and I
    don't need for them to be initialized to anything (eg. because right
    after the allocation I initialize them manually to some values), the
    std::vector will uselessly go through the allocated array, initializing
    every value with 0, right after which I go again through the vector and
    initialize the values to something else. This is wasted time.

    If I allocate the array with 'new', it won't do anything to it and it
    will be much faster.
     
    Juha Nieminen, Apr 13, 2008
    #4
  5. sk_usenet Guest

    "Juha Nieminen" <> wrote in message > Jerry Coffin
    wrote:
    >> As others have pointed out, the value is guaranteed to be zero.

    >
    > Sometimes I feel this is counter-productive speedwise.
    >
    > If I want to allocate a large array of, for example, integers and I
    > don't need for them to be initialized to anything (eg. because right
    > after the allocation I initialize them manually to some values), the
    > std::vector will uselessly go through the allocated array, initializing
    > every value with 0, right after which I go again through the vector and
    > initialize the values to something else. This is wasted time.
    >
    > If I allocate the array with 'new', it won't do anything to it and it
    > will be much faster.


    I think any statement without doing any actual measurements may not be true
    here. Also it would be a QoI issue.

    --
    http://techytalk.googlepages.com
     
    sk_usenet, Apr 13, 2008
    #5
  6. Andy Champ wrote:
    > To follow from Vladislav's post: to reserve() the space, then
    > initialise each one as you go, is most efficient.


    Yes, reserve() plus initializing with push_back() may be an
    improvement to the situation. However, I wonder if push_back() is as
    fast as a direct "array[index] = value;".
     
    Juha Nieminen, Apr 14, 2008
    #6
  7. Victor Bazarov schrieb:
    > Juha Nieminen wrote:
    >> Andy Champ wrote:
    >>> To follow from Vladislav's post: to reserve() the space, then
    >>> initialise each one as you go, is most efficient.

    >> Yes, reserve() plus initializing with push_back() may be an
    >> improvement to the situation. However, I wonder if push_back() is as
    >> fast as a direct "array[index] = value;".

    >
    > The difference is that 'push_back' copy-constructs using placement
    > 'new', whereas the other way would default-construct and then assign.
    > Basically, the total difference would be the final 'size()' times the
    > difference between {def-construct + assign} vs {copy-construct}.


    push_back() has to test the need for reallocation on each call, that makes
    it hard to unroll the loop and is a mess for the instruction pipeline etc...

    >
    > But it would have to be measured, not calculated.


    Thats the only way.

    --
    Thomas
    http://www.netmeister.org/news/learn2quote.html
    "Some folks are wise, and some otherwise."
     
    Thomas J. Gritzan, Apr 14, 2008
    #7
  8. Thomas J. Gritzan wrote:
    > push_back() has to test the need for reallocation on each call, that
    > makes it hard to unroll the loop and is a mess for the instruction
    > pipeline etc...


    And if we are using something like OpenMP, push_backs cannot be
    performed in parallel (while direct array initializations can, given
    that the values do not depend on each other).
     
    Juha Nieminen, Apr 14, 2008
    #8
  9. James Kanze Guest

    On Apr 13, 8:57 pm, Juha Nieminen <> wrote:
    > Jerry Coffin wrote:
    > > As others have pointed out, the value is guaranteed to be zero.


    > Sometimes I feel this is counter-productive speedwise.


    You mean you've actually had cases where an application wasn't
    fast enough because of it?

    > If I want to allocate a large array of, for example, integers and I
    > don't need for them to be initialized to anything (eg. because right
    > after the allocation I initialize them manually to some values), the
    > std::vector will uselessly go through the allocated array, initializing
    > every value with 0, right after which I go again through the vector and
    > initialize the values to something else. This is wasted time.


    You mean you've actually had an application which wasn't fast
    enough because of this?

    Of course, it's really very rare to initialize a vector like
    this unless you actually want all of the values to have the same
    value. Usually, you'll provide two iterators which generate the
    correct values. And yes, I know, it would be a lot easier and a
    lot more natural if only one were necessary, but Boost iterator
    can take a lot of the pain out of it.

    > If I allocate the array with 'new', it won't do anything to it
    > and it will be much faster.


    Using uninitialized memory to generate random results is
    probably faster than anything you can do with std::vector, yes.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Apr 15, 2008
    #9
  10. James Kanze Guest

    On Apr 15, 12:01 am, "Victor Bazarov" <> wrote:
    > Juha Nieminen wrote:
    > > Andy Champ wrote:
    > >> To follow from Vladislav's post: to reserve() the space,
    > >> then initialise each one as you go, is most efficient.


    > > Yes, reserve() plus initializing with push_back() may be an
    > > improvement to the situation. However, I wonder if
    > > push_back() is as fast as a direct "array[index] = value;".


    > The difference is that 'push_back' copy-constructs using
    > placement 'new', whereas the other way would default-construct
    > and then assign. Basically, the total difference would be the
    > final 'size()' times the difference between {def-construct +
    > assign} vs {copy-construct}.


    > But it would have to be measured, not calculated.


    The one time I measured, creating a vector< double > with all of
    the elements, then assigning, was faster than using puch_back.
    On my particular implementation. (I forget now whether I did
    the measurement on a Sparc under Solaris or a PC under Linux.)

    If speed is critical, use the two iterators constructor, and
    make sure it's a random access iterator. It's a little more
    work, but the case probably comes up so rarely that that's not
    an issue.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Apr 15, 2008
    #10
  11. Jerry Coffin Guest

    In article <48025350$0$23828$>,
    lid says...
    > Jerry Coffin wrote:
    > > As others have pointed out, the value is guaranteed to be zero.

    >
    > Sometimes I feel this is counter-productive speedwise.


    At least in theory, it is. OTOH, from a practical viewpoint, I've never
    run into a situation where it caused any problem at all.

    > If I want to allocate a large array of, for example, integers and I
    > don't need for them to be initialized to anything (eg. because right
    > after the allocation I initialize them manually to some values), the
    > std::vector will uselessly go through the allocated array, initializing
    > every value with 0, right after which I go again through the vector and
    > initialize the values to something else. This is wasted time.


    If you're going to initialize the values to some other values, why not
    supply those values when you create the vector? One of vector's ctors
    allows you to supply a couple of iterators to specify the values to use
    for initialization.

    If you know the number of values but not (yet) the values themselves,
    reserve the space but leave the vector empty, then put the values in
    when they're available.

    --
    Later,
    Jerry.

    The universe is a figment of its own imagination.
     
    Jerry Coffin, Apr 17, 2008
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Denis Remezov
    Replies:
    4
    Views:
    484
    Siemel Naran
    Apr 30, 2004
  2. Replies:
    3
    Views:
    713
    Shadowman
    Mar 26, 2008
  3. Replies:
    0
    Views:
    327
  4. Replies:
    3
    Views:
    586
    Rolf Magnus
    Apr 13, 2008
  5. Guest
    Replies:
    0
    Views:
    468
    Guest
    Sep 14, 2005
Loading...

Share This Page