c++ stl vector question

[nameless_centurian]

unfortunately, my stroustrup is a couple hours away and i am having difficulty understand the root cause of my error.

when i implement this

bool funct(cell& item,vector <cell*>& x);

i get this error

error: conversion from `__gnu_cxx::__normal_iterator<cell**, std::vector<cell*, std::allocator<cell*> > >' to non-scalar type `__gnu_cxx::__normal_iterator<cell*, std::vector<cell, std::allocator<cell> > >' requested

from this line

for(vector<cell>::iterator i = x.begin(); i != x.end(); i++)

i don't understand the origins of the error. i don't explicitly tell the compiler to make the conversion. why is it attempting to do so? it is obvious that i don't understand the semantics of the vector class (i'm a C programmer by nature). how can i store/iterate through a vector of pointers to objects?

 

[Arainach]

Because the function accepts a vector of cell pointers and you created an iterator for a vector of cells. Totally different.

 

[nameless_centurian]

yes, i feel silly now. forgot the *.

thanks!

 

[wuggle]

typedef vector <cell *> CellVector;

to avoid these things in the future. Also makes your code easier to understand when the templates get crazy.

 

[mikeblas]

You'll find that the STL collections aren't too eager to contain pointers to objects. they'd much rather have the actual objects, themselves.

 

[nameless_centurian]

i have read that and have experienced that. i'm lucky this program is more of an experiment for something used in the future that will likely be written in an entirely different language; it has let me introduce myself to the STL more than i had previously.

my logic for storing the pointers was twofold.

first, i'm instantiating the objects off the heap. i'm still in a C mindset and thought it was appropriate to store the pointer to the object so i could delete it later. thinking about it now, i guess i still have a reference to the object through this if i push the object on the vector.

secondly, wouldn't the copy constructor be called every time i push the object onto the vector? i think this would add a lot of unnecessary overhead. how do i mitigate this overhead?

 

[Cyrilix]

I'm pretty sure the STL has no problems at all storing regular pointers. I've done it hundreds, maybe thousands of times, without issue. That said, I don't think it's supposed to store smart pointers like auto_ptr.

 

[wuggle]

i have read that and have experienced that. i'm lucky this program is more of an experiment for something used in the future that will likely be written in an entirely different language; it has let me introduce myself to the STL more than i had previously.

my logic for storing the pointers was twofold.

first, i'm instantiating the objects off the heap. i'm still in a C mindset and thought it was appropriate to store the pointer to the object so i could delete it later. thinking about it now, i guess i still have a reference to the object through this if i push the object on the vector.

secondly, wouldn't the copy constructor be called every time i push the object onto the vector? i think this would add a lot of unnecessary overhead. how do i mitigate this overhead?

Yes, the copy constructor is called when you insert an item into a vector. That object is allocated on the heap, so in terms of memory usage, you're fine there. In terms of the overhead of a copy constructor, it depends on how light/heavy your data class is. If its just a couple strings/floats/ints, then it should be rather cheap. If you have a vector of vectors of vectors, you should probably re-think your data design

But really, the headache of dealing with pointer issues isn't worth the saved performance of not calling the copy constructor in most cases. If performance is a true issue, then you're probably better off implementing your own data storage class.

 

[Cyrilix]

Yes, the copy constructor is called when you insert an item into a vector. That object is allocated on the heap, so in terms of memory usage, you're fine there. In terms of the overhead of a copy constructor, it depends on how light/heavy your data class is. If its just a couple strings/floats/ints, then it should be rather cheap. If you have a vector of vectors of vectors, you should probably re-think your data design

But really, the headache of dealing with pointer issues isn't worth the saved performance of not calling the copy constructor in most cases. If performance is a true issue, then you're probably better off implementing your own data storage class.

What kind of issues would those be? As usual, you should remember to free your memory after you're done, and etc., but for most cases, why should a vector of pointers cause you any grief?

 

[nameless_centurian]

my data structure's instance variables only total 12 bytes. however, a ton of objects need to be created.

i find it curious that you don't think that there will be much of a performance hit for calling the copy constructor and then copying 12 bytes and then storing that object's reference on the vector as opposed to just copying 4 bytes onto the vector.

i guess i raise another question there... how are vectors implemented? is it in the standard? is it a dynamically re-sized array, or is it a linked data structure?

 

[mikeblas]

What kind of issues would those be? As usual, you should remember to free your memory after you're done, and etc., but for most cases, why should a vector of pointers cause you any grief?

The problem is that you don't know the lifespan of the pointer. And at that point, you've given up most of the benefit the collections have brought you. Since the STL is free to copy it anywhere it wants, and because you don't know where it's been copied, you don't know when it is safe to delete.

You can make it work, but it's pretty tedious.

The next problem is polymorphism. After you store pointers, the next thing you'll probably want is a pointer to a polymorphic class. You can't directly create a heterogeneous container in the STL, so you've got to do more work there.

It turns out that smart pointers are a way to solve some of these problems.