unsure about auto/smart pointers

Hello

Im unsure how I should use smart/auto pointer in this case:

I have a vector of pairs:

Code:

std::vector<std::pair<std::string, unsigned int>

Now I want vector to be a pointer, so it would be deleted when not needed anymore..
Should I make vector a smart/auto pointer, or each pair thats in vector smart/auto pointer or should I make both - vector and pairs pointers?

I tried:

Code:

typedef boost::shared_ptr<std::vector<std::pair<std::string, unsigned int> >> record_ptr;
record_ptr = new record_ptr(new (std::vector<std::pair<std::string, unsigned int> >));

But this wont compile..

Thanks for help

Regards

The compiler error helps to see, but...

Code:

typedef boost::shared_ptr<std::vector<std::pair<std::string, unsigned int> >> record_ptr;
record_ptr = new record_ptr(new (std::vector<std::pair<std::string, unsigned int> >));

Change that ">>" to a "> >", that's a problem with the C++ grammar.

This wont compile either.

Is this the right usage of smart pointers?
Maybe I should consider using shared_array?

The error:

Code:

error C2513: 'boost::shared_ptr<T>' : no variable declared before '='
        with
        [
            T=std::vector<std::pair<std::string,unsigned int>>
        ]

Code:

record_ptr = new record_ptr(new (std::vector<std::pair<std::string, unsigned int> >));

Why are you allocating the smart pointer with new?

Now I want vector to be a pointer, so it would be deleted when not needed anymore.

Stack variables get removed when the stack frame exits. Any specific reason you can't do it this way?

Should I make vector a smart/auto pointer, or each pair thats in vector smart/auto pointer or should I make both - vector and pairs pointers?

Completely dependent on what you need the indirection for. (But note that it is forbidden to store auto_ptrs in containers.) However, the fact that you don't immediately know which the right way is suggests that you don't need either. See above.

Originally Posted by l2u

Hello

Im unsure how I should use smart/auto pointer in this case:

I have a vector of pairs:

Code:

std::vector<std::pair<std::string, unsigned int>

Now I want vector to be a pointer, so it would be deleted when not needed anymore..
Should I make vector a smart/auto pointer, or each pair thats in vector smart/auto pointer or should I make both - vector and pairs pointers?

Just use a vector directly. When you no longer want it to hold on to a large amount of memory, do this:

Code:

typedef std::vector<std::pair<std::string, unsigned int> > StringIntVec;
StringIntVec m_myVec;
m_myVec.resize(10000);
// m_myVec uses lots of memory

StringIntVec dummy;
m_myVec.swap(dummy);
// m_myVec no longer uses lots of memory

You don't need to wrap a vector in a smart pointer. A vector already does the memory management for you. Of course if you have other reasons for wanting to use dynamic allocation of the vector variable itself, then by all means let us know.

Or to avoid the explicit dummy variable,

Code:

StringIntVec().swap(m_myVec);

Controlling a Container’s Capacity

Originally Posted by iMalc

You don't need to wrap a vector in a smart pointer. A vector already does the memory management for you. Of course if you have other reasons for wanting to use dynamic allocation of the vector variable itself, then by all means let us know.

I want to wrap it in a smart pointer because I have a function that parses some data and puts it inside a vector.. I want this vector to be stored and used somewhere else in the program (the object that parses data is deleted after parsing is done). I still want to keep the vector, and dont want to copy it or pass the reference around..

Isnt that the reason why should I wrap the vector with smart pointer?

Yes. That makes sense. Wrapping the vector in the smart pointer is a better choice IMO than storing pointers in the vector.

That sounds like a reason to use an iterator, actually, although I really don't see the problem with passing a reference either. It's a lightweight and simple solution.

Thank you guys for help!

However, theres one thing that still isnt clear to me.

Originally Posted by CornedBee

But note that it is forbidden to store auto_ptrs in containers.

Why would that be forbidden?

auto_ptr's don't copy normally, they transfer ownership of the pointer. Since the vector will sometimes make several copies of an object, it is possible that the last copy made (the one with the ownership) is not the one stored in the vector. That means the copy stored in the vector is in a bad state and the data is lost or worse.

Originally Posted by l2u

I want to wrap it in a smart pointer because I have a function that parses some data and puts it inside a vector.. I want this vector to be stored and used somewhere else in the program (the object that parses data is deleted after parsing is done). I still want to keep the vector, and dont want to copy it or pass the reference around..

Isnt that the reason why should I wrap the vector with smart pointer?

I can see where you're coming from. Wanting to not copy the vector makes perfect sense.
However, in order to keep the vector, you can just do the swap trick I just demonstrated. Swap the one that is about to be destroyed with the vector you want to keep it in. Internally it only involves swapping 3 pointer values and you have transferred the entire vector contents between the vectors. The lack of dynamically allocating a vector really doesn't hinder the kind of stuff you want to do at all so far.
So, got any other reasons?

In particular, what is the relationship between the final location of the vector and the object that parses data? Passing a reference to the vector to this object may well be the better solution.

Code:

class parser {
public:
	std::vector<std::string> vector_;
};

class cache {
public:
	std::map<std::string, std::vector<std::string> > map_;
};

//somewhere
{
parser p();
p.parse();
// now I have vector_ in parser class and want to store it in map (inside cache class) - parser is going to be destroyed
}

In this case, would swap be better option?

I like the shared_ptr option. You're storing it in the map, too, which matters a little. I don't think there's a ton of copying done with maps, but still, the container might be copying the value itself. Using a shared_ptr minimizes that copying.

Oh, and apparently this whole thing will be much nicer in C++09. Can you wait til then?