pointer vectors

Discussion in 'C++' started by john townsley, Mar 1, 2005.

  1. when using vectors with pointers of objects. is it best to create instances
    then point to them or dynamic allocation upon creating a vector element.
    I can do this, but is creating a vector with pointer to objects best done
    like this...with dynamic allocation


    vector<emp_class*> ptvector;
    ptvector.push_back(new emp_class(4,"ee"));
    cout<<ptvector->....


    ....this works but is it effeicient
     
    john townsley, Mar 1, 2005
    #1
    1. Advertising

  2. "john townsley" <> wrote...
    > when using vectors with pointers of objects. is it best to create
    > instances then point to them or dynamic allocation upon creating a vector
    > element.
    > I can do this, but is creating a vector with pointer to objects best done
    > like this...with dynamic allocation
    >
    >
    > vector<emp_class*> ptvector;
    > ptvector.push_back(new emp_class(4,"ee"));
    > cout<<ptvector->....
    >
    >
    > ...this works but is it effeicient


    Why is the question of efficiency? Dynamic object creation is done not
    for efficiency reasons but for the specifics of their lifetime (objects
    created in the free store survive the scope they are created in). The
    performance concerns should only be addressed if it's proven that they
    are founded.

    V
     
    Victor Bazarov, Mar 1, 2005
    #2
    1. Advertising

  3. "Victor Bazarov" <> wrote in message
    news:...
    > "john townsley" <> wrote...
    >> when using vectors with pointers of objects. is it best to create
    >> instances then point to them or dynamic allocation upon creating a vector
    >> element.
    >> I can do this, but is creating a vector with pointer to objects best done
    >> like this...with dynamic allocation
    >>
    >>
    >> vector<emp_class*> ptvector;
    >> ptvector.push_back(new emp_class(4,"ee"));
    >> cout<<ptvector->....
    >>
    >>
    >> ...this works but is it effeicient

    >
    > Why is the question of efficiency? Dynamic object creation is done not
    > for efficiency reasons but for the specifics of their lifetime (objects
    > created in the free store survive the scope they are created in). The
    > performance concerns should only be addressed if it's proven that they
    > are founded.
    >
    > V
    >


    i wanted to know is this how you created vector of pointer to objects? is
    there anything to be awate of or is there a better way?
     
    john townsley, Mar 1, 2005
    #3
  4. "john townsley" <> wrote...
    >
    > "Victor Bazarov" <> wrote in message
    > news:...
    >> "john townsley" <> wrote...
    >>> when using vectors with pointers of objects. is it best to create
    >>> instances then point to them or dynamic allocation upon creating a
    >>> vector element.
    >>> I can do this, but is creating a vector with pointer to objects best
    >>> done like this...with dynamic allocation
    >>>
    >>>
    >>> vector<emp_class*> ptvector;
    >>> ptvector.push_back(new emp_class(4,"ee"));
    >>> cout<<ptvector->....
    >>>
    >>>
    >>> ...this works but is it effeicient

    >>
    >> Why is the question of efficiency? Dynamic object creation is done not
    >> for efficiency reasons but for the specifics of their lifetime (objects
    >> created in the free store survive the scope they are created in). The
    >> performance concerns should only be addressed if it's proven that they
    >> are founded.
    >>
    >> V
    >>

    >
    > i wanted to know is this how you created vector of pointer to objects? is
    > there anything to be awate of or is there a better way?


    The main thing to be aware of is the necessity to handle object properly
    when deleting the vector element. The vector does not know that you got
    your object from the free store and therefore will not attempt to delete
    it for you. You have do to it yourself. An alternative is to create the
    vector not of pointers but of objects of type 'smart pointer' or something
    like that. Do not use 'std::auto_ptr' though, it is not suitable. Look for
    a better implementation, like in the Boost library.

    AIUI, there are two instances where you want to have a vector of some
    pointer
    type. One is when you want to store a pointer to a base class and maintain
    polymorphic access to objects of [different] derived types, and the other
    one
    is when the lifetime of the objects is not necessarily controlled by the
    object's visibility. Of course you can have both instances together, they
    are not mutually exclusive, but rather orthogonal.

    V
     
    Victor Bazarov, Mar 1, 2005
    #4
  5. john townsley

    SpOiLeR Guest

    On Tue, 1 Mar 2005 00:03:12 -0500, Victor Bazarov wrote:

    > AIUI, there are two instances where you want to have a vector of some
    > pointer
    > type. One is when you want to store a pointer to a base class and maintain
    > polymorphic access to objects of [different] derived types, and the other
    > one
    > is when the lifetime of the objects is not necessarily controlled by the
    > object's visibility. Of course you can have both instances together, they
    > are not mutually exclusive, but rather orthogonal.
    >
    > V


    What if I have a vector of really BigObject? I mean, when vector gets
    resized it must: allocate more memory, call copy constructors for all
    elements and finally call destructors after copy is done. For BigObject
    this results in both memory and speed performance loss. Wouldn't this be
    the third type of situation when it is better to hold pointers in vector
    than objects itself? Here, by pointers I mean some kind of smart objects
    that are smaller than original objects and do creation/destruction of
    BigObject automatically. Copying these pointer objects wouldn't touch
    BigObjects on the heap, just pointers to them, which is probably faster,
    and definitely uses less "temporary" memory.
     
    SpOiLeR, Mar 4, 2005
    #5
  6. SpOiLeR wrote:
    > On Tue, 1 Mar 2005 00:03:12 -0500, Victor Bazarov wrote:
    >
    >
    >>AIUI, there are two instances where you want to have a vector of some
    >>pointer
    >>type. One is when you want to store a pointer to a base class and maintain
    >>polymorphic access to objects of [different] derived types, and the other
    >>one
    >>is when the lifetime of the objects is not necessarily controlled by the
    >>object's visibility. Of course you can have both instances together, they
    >>are not mutually exclusive, but rather orthogonal.
    >>
    >>V

    >
    >
    > What if I have a vector of really BigObject? I mean, when vector gets
    > resized it must: allocate more memory, call copy constructors for all
    > elements and finally call destructors after copy is done. For BigObject
    > this results in both memory and speed performance loss. Wouldn't this be
    > the third type of situation when it is better to hold pointers in vector
    > than objects itself? Here, by pointers I mean some kind of smart objects
    > that are smaller than original objects and do creation/destruction of
    > BigObject automatically. Copying these pointer objects wouldn't touch
    > BigObjects on the heap, just pointers to them, which is probably faster,
    > and definitely uses less "temporary" memory.


    If you anticipate frequent resizing of your container, perhaps std::vector
    is not the best choice? See other threads and publications to learn more
    on how to pick the proper container for your needs.

    You should, of course, think about possible performance implications of
    any decision you're making in the process of creating your software. Just
    don't be making wrong ones based on incomplete analysis of the problem
    domain requirements.

    V
     
    Victor Bazarov, Mar 4, 2005
    #6
  7. john townsley

    SpOiLeR Guest

    On Fri, 04 Mar 2005 09:09:36 -0500, Victor Bazarov wrote:

    > SpOiLeR wrote:
    >> On Tue, 1 Mar 2005 00:03:12 -0500, Victor Bazarov wrote:
    >>
    >>
    >>>AIUI, there are two instances where you want to have a vector of some
    >>>pointer
    >>>type. One is when you want to store a pointer to a base class and maintain
    >>>polymorphic access to objects of [different] derived types, and the other
    >>>one
    >>>is when the lifetime of the objects is not necessarily controlled by the
    >>>object's visibility. Of course you can have both instances together, they
    >>>are not mutually exclusive, but rather orthogonal.
    >>>
    >>>V

    >>
    >>
    >> What if I have a vector of really BigObject? I mean, when vector gets
    >> resized it must: allocate more memory, call copy constructors for all
    >> elements and finally call destructors after copy is done. For BigObject
    >> this results in both memory and speed performance loss. Wouldn't this be
    >> the third type of situation when it is better to hold pointers in vector
    >> than objects itself? Here, by pointers I mean some kind of smart objects
    >> that are smaller than original objects and do creation/destruction of
    >> BigObject automatically. Copying these pointer objects wouldn't touch
    >> BigObjects on the heap, just pointers to them, which is probably faster,
    >> and definitely uses less "temporary" memory.

    >
    > If you anticipate frequent resizing of your container, perhaps std::vector
    > is not the best choice? See other threads and publications to learn more
    > on how to pick the proper container for your needs.
    >


    Hm, but let's say I need random access to container elements. This is
    allowed only by vector container (I simulated it with std::list using
    iterator that always started from begin() and moved through list until
    specified member reached, but of course it was slower than vector). If I
    expect from 100 to few 1000s BigObjects to be stored in container, and if I
    need random access, but also expect objects will be freely inserted/removed
    than what's better: list or vector. Using vector, reallocation takes quite
    a time (and reserving vector memory for, let's say 10000, BigObjects each
    time seems quite a waste), but using list access takes longer time. The
    only thing that seems to solve this problem is vector of pointers. The
    question is, how to do it safely? I've been googling around and found boost
    smart_ptr library which could do the trick.
    Anyway, all I wanted to say, is that maybe this is another situation where
    pointers in vector (and vector specifically, not STL containers generally)
    may be needed when performance is considered.
     
    SpOiLeR, Mar 4, 2005
    #7
  8. SpOiLeR wrote:
    > On Fri, 04 Mar 2005 09:09:36 -0500, Victor Bazarov wrote:
    >
    >
    >>SpOiLeR wrote:
    >>
    >>>On Tue, 1 Mar 2005 00:03:12 -0500, Victor Bazarov wrote:
    >>>
    >>>
    >>>
    >>>>AIUI, there are two instances where you want to have a vector of some
    >>>>pointer
    >>>>type. One is when you want to store a pointer to a base class and maintain
    >>>>polymorphic access to objects of [different] derived types, and the other
    >>>>one
    >>>>is when the lifetime of the objects is not necessarily controlled by the
    >>>>object's visibility. Of course you can have both instances together, they
    >>>>are not mutually exclusive, but rather orthogonal.
    >>>>
    >>>>V
    >>>
    >>>
    >>>What if I have a vector of really BigObject? I mean, when vector gets
    >>>resized it must: allocate more memory, call copy constructors for all
    >>>elements and finally call destructors after copy is done. For BigObject
    >>>this results in both memory and speed performance loss. Wouldn't this be
    >>>the third type of situation when it is better to hold pointers in vector
    >>>than objects itself? Here, by pointers I mean some kind of smart objects
    >>>that are smaller than original objects and do creation/destruction of
    >>>BigObject automatically. Copying these pointer objects wouldn't touch
    >>>BigObjects on the heap, just pointers to them, which is probably faster,
    >>>and definitely uses less "temporary" memory.

    >>
    >>If you anticipate frequent resizing of your container, perhaps std::vector
    >>is not the best choice? See other threads and publications to learn more
    >>on how to pick the proper container for your needs.
    >>

    >
    >
    > Hm, but let's say I need random access to container elements. This is
    > allowed only by vector container (I simulated it with std::list using
    > iterator that always started from begin() and moved through list until
    > specified member reached, but of course it was slower than vector). If I
    > expect from 100 to few 1000s BigObjects to be stored in container, and if I
    > need random access, but also expect objects will be freely inserted/removed
    > than what's better: list or vector.


    deque.

    > Using vector, reallocation takes quite
    > a time (and reserving vector memory for, let's say 10000, BigObjects each
    > time seems quite a waste), but using list access takes longer time. The
    > only thing that seems to solve this problem is vector of pointers. The
    > question is, how to do it safely? I've been googling around and found boost
    > smart_ptr library which could do the trick.


    Probably.

    > Anyway, all I wanted to say, is that maybe this is another situation where
    > pointers in vector (and vector specifically, not STL containers generally)
    > may be needed when performance is considered.


    Maybe. What I wanted to say, don't just consider performance when
    choosing your design.

    V
     
    Victor Bazarov, Mar 4, 2005
    #8
    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. Replies:
    10
    Views:
    706
    Chris Torek
    Feb 4, 2005
  2. jimjim
    Replies:
    16
    Views:
    844
    Jordan Abel
    Mar 28, 2006
  3. Replies:
    3
    Views:
    702
    Shadowman
    Mar 26, 2008
  4. Replies:
    4
    Views:
    1,270
    Fred Zwarts
    Jul 2, 2009
  5. Guest
    Replies:
    0
    Views:
    448
    Guest
    Sep 14, 2005
Loading...

Share This Page