Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > pointer vectors

Reply
Thread Tools

pointer vectors

 
 
john townsley
Guest
Posts: n/a
 
      03-01-2005
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


 
Reply With Quote
 
 
 
 
Victor Bazarov
Guest
Posts: n/a
 
      03-01-2005
"john townsley" <(E-Mail Removed)> 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


 
Reply With Quote
 
 
 
 
john townsley
Guest
Posts: n/a
 
      03-01-2005

"Victor Bazarov" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "john townsley" <(E-Mail Removed)> 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?


 
Reply With Quote
 
Victor Bazarov
Guest
Posts: n/a
 
      03-01-2005
"john townsley" <(E-Mail Removed)> wrote...
>
> "Victor Bazarov" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> "john townsley" <(E-Mail Removed)> 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[s] properly
when deleting the vector element[s]. 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


 
Reply With Quote
 
SpOiLeR
Guest
Posts: n/a
 
      03-04-2005
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.
 
Reply With Quote
 
Victor Bazarov
Guest
Posts: n/a
 
      03-04-2005
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
 
Reply With Quote
 
SpOiLeR
Guest
Posts: n/a
 
      03-04-2005
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.
 
Reply With Quote
 
Victor Bazarov
Guest
Posts: n/a
 
      03-04-2005
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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Pointer to pointer Vs References to Pointer bansalvikrant@gmail.com C++ 4 07-02-2009 10:20 AM
c++ primer statement about vectors containing vectors pauldepstein@att.net C++ 3 03-26-2008 06:22 PM
passing the address of a pointer to a func that doesnt recieve a pointer-to-a-pointer jimjim C Programming 16 03-27-2006 11:03 PM
Ruby, SWIG and C++: how to properly wrap vector of vectors of doubles (2D vectors)? Ruby 0 09-14-2005 05:47 PM
Pointer-to-pointer-to-pointer question masood.iqbal@lycos.com C Programming 10 02-04-2005 02:57 AM



Advertisments