Keeping a vector in a class: pointer or object??
Neil Butterworth
"John Barclay" <j...@yahoo.nospam.com> wrote in message
news:qc1hvus1dvgn3tkd7...@4ax.com...
> My code is very inconsistent on this: there are lots of places where I
> have classes containing vectors, and lots of places where I have
> classes containing pointers to vectors. What's the feeling on the best
> way to do this - what are the tradeoffs involved?
>
> In my (simplistic, probably incorrect) view:
>
> 1) Object:
> + No need to 'new' a vector in the constructor:
> it already exists
> - Vector grows/shrinks inside the class - does
> this mean that there's extra overhead in
> growing/shrinking the vector?
No more so than if you use a pointer.
> + Class destructor automatically deletes the vector
>
> 2) Ptr to vector:
> - Vector must be explicitly created with new in
> the class constructor
> + The vector grows/shrinks on the heap, and doesn't
> affect the rest of the class
Works identically in both cases.
> - Class destructor must explicitly delete the vector
> (is this true?)
Yes.
In general, never create an object dynamically if you can avoid it. In this
specific case you can always use a contained vector instead of a pointer and
should prefer to do so.
NeilB
John Barclay
have classes containing vectors, and lots of places where I have
classes containing pointers to vectors. What's the feeling on the best
way to do this - what are the tradeoffs involved?
In my (simplistic, probably incorrect) view:
1) Object:
+ No need to 'new' a vector in the constructor:
it already exists
- Vector grows/shrinks inside the class - does
this mean that there's extra overhead in
growing/shrinking the vector?
+ Class destructor automatically deletes the vector
2) Ptr to vector:
- Vector must be explicitly created with new in
the class constructor
+ The vector grows/shrinks on the heap, and doesn't
affect the rest of the class
- Class destructor must explicitly delete the vector
(is this true?)
Many thanks
John
Alf P. Steinbach
>My code is very inconsistent on this: there are lots of places where I
>have classes containing vectors, and lots of places where I have
>classes containing pointers to vectors. What's the feeling on the best
>way to do this - what are the tradeoffs involved?
>
>In my (simplistic, probably incorrect) view:
>
>1) Object:
> + No need to 'new' a vector in the constructor:
> it already exists
> - Vector grows/shrinks inside the class - does
> this mean that there's extra overhead in
> growing/shrinking the vector?
Up to some limit it may grow/shrink within a buffer that's part of
the vector object, but that depends on the implementation (and I don't
know any implementation that does this). Over some limit, however,
a std::vector -- assuming that's what we're talking about --
must allocate memory from the heap.
> + Class destructor automatically deletes the vector
>
>2) Ptr to vector:
> - Vector must be explicitly created with new in
> the class constructor
Not necessarily, but the pointer must point to a valid vector
object before the pointer is used. This can be accomplished
in many different ways. One way is the way described above.
The main difference is that if your object should always
contain a vector, then the pointer is _unsafe_.
In that case, don't use a pointer to vector, use a vector.
> + The vector grows/shrinks on the heap, and doesn't
> affect the rest of the class
Not necessarily, and this situation is in general not different
from vector as direct part of your object (just some details).
> - Class destructor must explicitly delete the vector
> (is this true?)
No, it isn't true.
But if an object X contains a pointer to a vector V, which it
has allocated dynamically, then it's a good idea to let the
object X also be responsible for deallocation og V, which of
must then happen before the X destructor execution completes.
Hth.,
- Alf (novice helper mode)
Adrian Cornish
>
> My code is very inconsistent on this: there are lots of places where I
> have classes containing vectors, and lots of places where I have
> classes containing pointers to vectors. What's the feeling on the best
> way to do this - what are the tradeoffs involved?
>
> In my (simplistic, probably incorrect) view:
>
> 1) Object:
> + No need to 'new' a vector in the constructor:
> it already exists
> - Vector grows/shrinks inside the class - does
> this mean that there's extra overhead in
> growing/shrinking the vector?
NB. Vectors do not shrink in size, they only grow. (95% sure on this
but I hope someone will correct me if I am wrong)
--
Adrian Cornish
AP
Website: www.bluedreamer.com
Jon Bell
John Barclay <j...@yahoo.nospam.com> wrote:
>
>1) Object:
> - Vector grows/shrinks inside the class - does
> this mean that there's extra overhead in
> growing/shrinking the vector?
The vector can grow/shrink, but it does not do so inside the class. The
memory used by the vector is in two parts. One part contains bookkeeping
information, basically a count of the number of items in the vector, and a
pointer to the actual data. This part is stored as part of your class,
and is fixed in size. The other part contains the actual vector data, and
is allocated on the heap for you by the vector member functions. It can
vary in size, but it's not actually part of your class's memory
allocation.
>2) Ptr to vector:
> + The vector grows/shrinks on the heap, and doesn't
> affect the rest of the class
This is true for case 1) also.
To verify this, create a vector, do sizeof() on it, then change its size,
and do sizeof() again. I always get 12 when I do a sizeof() on a vector.
(g++ under Solaris).
--
Jon Bell <jtbe...@presby.edu> Presbyterian College
Dept. of Physics and Computer Science Clinton, South Carolina USA
Karl Heinz Buchegger
John Barclay wrote:
>
> In my (simplistic, probably incorrect) view:
I summarized your simplistic view to the real differences
>
> 1) Object:
+ No need to manage the vector,
since the vector object does this
all by itself.
>
> 2) Ptr to vector:
- the class needs to manage the dynamically
allocated vector.
This includes:
* constructor
* copy constructor
* destructor
* assignment operator
--
Karl Heinz Buchegger
kbuc...@gascad.at
Homer Meyer
> have classes containing vectors, and lots of places where I have
> classes containing pointers to vectors. What's the feeling on the best
> way to do this - what are the tradeoffs involved?
>
> In my (simplistic, probably incorrect) view:
>
> 1) Object:
> + No need to 'new' a vector in the constructor:
> it already exists
> - Vector grows/shrinks inside the class - does
> this mean that there's extra overhead in
> growing/shrinking the vector?
+ Vector grows/shrinks on the free store (with many compilers this is the
heap). Only a small amount of space that the vector uses to manage the
memory it allocates on the free store is included in the object's size.
+ The compiler generated copy constructor does the right thing.
+ The compiler generated assignment operator does the right thing.
> + Class destructor automatically deletes the vector
>
> 2) Ptr to vector:
> - Vector must be explicitly created with new in
> the class constructor
- Must declare copy constructor and assignment operator private and leave
them unimplemented. (This may not be a negative. It depends on the class.
But you can do the same thing if the vector is a part of the object. So,
the fact that you must do it here, or write them correctly yourself is a
negative.)
or
- Must have a user-defined copy constructor that must explicitly create the
vector with new.
- Must have a user-defined assigment operator that does the right thing.
> + The vector grows/shrinks on the heap, and doesn't
> affect the rest of the class
There isn't a significant difference here.
> - Class destructor must explicitly delete the vector
> (is this true?)
The main reasons to use the pointer are:
1) You want to explicitly control the allocation and deallocation. Maybe
you don't want to allocate the object in the constructor, but only later and
only if it is needed.
2) You are using polymorphism. In this case you need the pointer because
you don't know the actual type of the object.
3) The object is owned by some other entity. In this case you want to
access the object, but you don't want to go to the expense of making a copy
or making a copy is not possible (ie, stream objects).
4) The object is passed into the class from outside and making a copy is
expensive or not possible. Your class takes onwership but does not create
the object.
There may be others that I have missed, but I think this covers the main
reasons to store pointers inside a class.
John Harrison
> have classes containing vectors, and lots of places where I have
> classes containing pointers to vectors. What's the feeling on the best
> way to do this - what are the tradeoffs involved?
>
> In my (simplistic, probably incorrect) view:
>
> 1) Object:
> + No need to 'new' a vector in the constructor:
> it already exists
> - Vector grows/shrinks inside the class - does
> this mean that there's extra overhead in
> growing/shrinking the vector?
No
> + Class destructor automatically deletes the vector
>
> 2) Ptr to vector:
> - Vector must be explicitly created with new in
> the class constructor
> + The vector grows/shrinks on the heap, and doesn't
> affect the rest of the class
It grows/shrinks on the heap whatever.
> - Class destructor must explicitly delete the vector
> (is this true?)
Yes, you newed it you must delete it.
>
> Many thanks
>
> John
As you can see none of your advantages for a pointer and disadvantages for
an object count for anything. By using a pointer you throw away many of the
advantages of the vector class, the need to allocate memory, the need to
write copy constructors and assignment operators, and the exception safety.
Don't use pointers without *good* reason.
john
John Harrison
> NB. Vectors do not shrink in size, they only grow. (95% sure on this
> but I hope someone will correct me if I am wrong)
>
To be accurate, the standard does not require vectors to shrink (in terms of
capacity) but it doesn't prevent them from doing so either.
john
Adrian Cornish
For the sake of discussion, maybe it does prevent it.
Having a closer read of the standards, it says for erase the following
effect must happen.
23.2.4.3.3 Effects: Invalidates all the iterators and references after
the point of the erase.
Since some of the iterators remain valid then I assume this would be
impossible if the vector reallocated the memory. Since the vector uses
an Allocator, which has no realloc functionality (that I can see), it
uses new and delete.
Just idle speculation really.
Dimitris Kamenopoulos
>>1) Object:
>> + No need to 'new' a vector in the constructor:
>> it already exists
>> - Vector grows/shrinks inside the class - does
>> this mean that there's extra overhead in
>> growing/shrinking the vector?
>
> Up to some limit it may grow/shrink within a buffer that's part of
> the vector object, but that depends on the implementation (and I don't
> know any implementation that does this).
I believe this is only viable for strings (it is actually called small
string optimization), because vectors need to be contiguous and using the
small string optimization would complicate matters.
Jerry Coffin
d.kamen...@mail.ntua.gr says...
[ ... ]
> I believe this is only viable for strings (it is actually called small
> string optimization), because vectors need to be contiguous and using the
> small string optimization would complicate matters.
You could use a small-vector optimization the same way without any
problem. When the vector got too large to be stored in the vector body,
you'd allocate new memory and copy the current contents from the body to
the spot allocated with new. The data would remain contiguous.
--
Later,
Jerry.
The universe is a figment of its own imagination.
John Barclay
wrote:
> <snipped>
Many thanks everybody - I'm busy deleting all those pointers. Too much
C in me.
Cheers
JB
Jon Bell
John Barclay <j...@yahoo.nospam.com> wrote:
>
>Many thanks everybody - I'm busy deleting all those pointers. Too much
>C in me.
If you write C++ in a modern style using the standard library as much as
possible, you'll find that you don't need pointers nearly as often as you
do in C.
I teach a two-semester intro programming sequence based on C++, and I have
trouble teaching pointers because it's hard to find good examples to
motivate their use at that level. Using std::vector eliminates the need
for pointers and new[] to allocate arrays whose size is only known at run
time. Using std::string eliminates the need for char*. We don't get far
enough in these courses to do linked lists (we have an algorithms and data
structures course for that) and for practical use the standard containers
(std::list, etc.) are usually better than homebrew containers anyway.
John Barclay
wrote:
>In article <le8jvucj2jqrg8rof...@4ax.com>,
>John Barclay <j...@yahoo.nospam.com> wrote:
>>
>>Many thanks everybody - I'm busy deleting all those pointers. Too much
>>C in me.
>
>If you write C++ in a modern style using the standard library as much as
>possible, you'll find that you don't need pointers nearly as often as you
>do in C.
>
>I teach a two-semester intro programming sequence based on C++, and I have
>trouble teaching pointers because it's hard to find good examples to
>motivate their use at that level. Using std::vector eliminates the need
>for pointers and new[] to allocate arrays whose size is only known at run
>time. Using std::string eliminates the need for char*.
Ahh - I'm also busy getting rid of those char *'s - that's a bit
trickier, though. (x)printf and (x)scanf are just too useful. Or,
possibly, their replacements are just too complex or too difficult to
find good and simple documentation on.. not sure yet.
JB
Dave Mikesell
> If you write C++ in a modern style using the standard library as much as
> possible, you'll find that you don't need pointers nearly as often as you
> do in C.
>
> I teach a two-semester intro programming sequence based on C++, and I have
> trouble teaching pointers because it's hard to find good examples to
> motivate their use at that level.
Would the use of legacy code/libraries be appropriate? That's about
the only time I use pointers now - when a 3rd party library requires
them.
> Using std::vector eliminates the need
> for pointers and new[] to allocate arrays whose size is only known at run
> time. Using std::string eliminates the need for char*. We don't get far
> enough in these courses to do linked lists (we have an algorithms and data
> structures course for that) and for practical use the standard containers
> (std::list, etc.) are usually better than homebrew containers anyway.
Yep. I laugh when people tell me how "dangerous" it is to program in
C++. And I cry when I see new C++ code that doesn't take advantage
of the standard library.
Adrian Cornish
I used to think that (coming from a c background as well), have a look
at stringstreams. They are just as easy to use as printf() family
(although you need a bit more typing).