Addressof Unary Functor

[bramp]

Hi,
I have an vector of objects

std::vector<Class> v1;

and now I want to make a vector of Class *, which index pointing to a element in v1. for example

std::vector<Class *> v2;
v2[0] = &v1[0]

I can easily do this by writing the following loop

v2.reserve ( v1.size() );
for (vector<Class>::iterator it = v1.begin(); it != v1.end(); it++) {
    v2.push_back ( &(*it) );
}

But I wanted to do this in a more STL style way, so I used a transform:

transform (v1.begin(), v1.territories.end(), v2.begin(), addressof<Class>() );

However, the addressof unary functor doesn't exist, so I coded one like so:

template <class T> struct addressof : std::unary_function <T,T> {
  T* operator() (T& x) const
    {return &x;}
};

Now my two questions are,
1) Does a functor like addressof already exist?
2) Is there anything wrong/weird with my approach?

I wanted to create an array of Class *, so I could quickly shuffle the array without copying the class instance many times. e.g.

random_shuffle ( v2.begin(), v2.end() );

I know that my v2 array will contain invalid pointers if v1 changes, however, once v1 is setup it will never grow/shrink.

thanks
Andrew

[Hermit]

Now my two questions are,
1) Does a functor like addressof already exist?

None that I'm aware of.

2) Is there anything wrong/weird with my approach?

Seems fine to me. It did seem a bit odd that you would create a second array of pointers to every element in another array, but then I saw the last part of your post. You might avoid the invalid pointer thing by storing indexes in the second array instead of pointers, though.

[Graham]

I know that my v2 array will contain invalid pointers if v1 changes, however, once v1 is setup it will never grow/shrink.

...until a day or two after this assumption gets deeply embedded into the code, at which point the requirements will change in such a way as to make the assumption invalid.





Cynical? Me?


But it will happen...

[bramp]

Cynical? Me?

But it will happen...

A little paranoid perhaps, but I am aware of the problem.

Well just out of interest, lets consider a different solutions, but first I will provide some background.

I'm creating a program to play the game Risk. Risk has a fixed number of territories (countries) that you try and conquer. I create one instance of a Territory class for each territory on the map and store it in my vector v1. Now I know that the number will stay fixed for the duration of the game, hence I'm not worried that v1 will change. However, if we want to be paranoid and assume it might, would the correct way be to store pointers to new'd Territory classes?

The reason I didn't want to use new, was that if the object pointer is removed from the vector it is not automatically delete'd, whereas if I don't store pointers it is. eg:

Vector <Class *> v1;
v1.push_back ( new Class("England") );
v1.push_back ( new Class("France") );
// some time latter
v1.clear();
// Now I've leaked memory, because I forgot to remove (and delete) one by one

Now since several parts of my code needs access to these Territory classes I will only ever pass pointers or references to the instances stored in the vector, i.e

Vector <Class> v1;
v1.push_back ( Class("England") );
// some where else
Class *blah = &v1[0];

So I see no problem doing this unless the vector is changed mid-game.

Maybe someone can suggest a different approach, or perhaps why using new/delete is still better? Or suggest a way to guarantee I don't leak memory if I clear the vector<Class *>.

thanks
Andrew

[Hermit]

The reason I didn't want to use new, was that if the object pointer is removed from the vector it is not automatically delete'd, whereas if I don't store pointers it is.

You may want to have a look at boost's ptr_vector class. It will, by default, automatically delete pointers when they are removed from the container.

Another option would be to use a vector of smart pointers. In this case you can use tr1::shared_ptr, which unlike the boost libraries probably comes with your compiler.

[potatoCode]

Hello bramp

I'm not 100% sure about what I'm about to say, so plz bear with me!
If the point of removing a territory class (v1.clear()) is to indicate that the territory has been conquered, then, I don't think removing it from the vector is the best choice in this case.
because it can only signal two state of conditions.

how about you create a table of function objects to point to each territory class,
and use the pointer to indicate the current state of the territory?
So in this way, you not only have more options to indicate territory's current conditions,
but don't have to worry too much about having those map classes on the heap.
but then again..i think you need a global member (but not static) to do that.
hm, does this any make sense to you?
hm...i don't know.

[JohnW@Wessex]

One other option could be to store your data in a std::list instead of a std::vector. Then random_shuffle would not be so great an overhead as the data itself will not move.

[bramp]

I'm not 100&#37; sure about what I'm about to say, so plz bear with me!
If the point of removing a territory class (v1.clear()) is to indicate that the territory has been conquered, then, I don't think removing it from the vector is the best choice in this case.
because it can only signal two state of conditions.

Sorry, I think you miss understood... The vector of territories will not change throughout the game. It is a list of all territories, not just the ones which aren't conquered.

I will have other vectors storing which are owned by which player, and which aren't conquered, etc. But these will be vectors of pointers.