Jump to content
  • Advertisement
Sign in to follow this  
moucard

C++, STL, putting multimaps in a vector

This topic is 4810 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi to everyone. I'll be holding some stuff in a multimap. The problem is I want to have 2, 3 or multimaps to contain different level path. I've created a vector of these like:
vector<multimap<int, int> > paths;
Now I need to initialize the vector. I try to do something like:
paths.push_back(new multimap<int, int>);
but I get compile errors. What is the correct way? If I resize the vector does he automatically create the objects for me? Later on what I want to do is:
                getline(ifsMaze, fileline);
		tmpPair.first  = atoi(fileline.c_str());
		tmpPair.second = atoi(fileline.substr(fileline.find(' ', 1) + 1, 10).c_str());
		paths[0].insert(tmpPair);	

Share this post


Link to post
Share on other sites
Advertisement
You've declared a "vector of multimaps that maps ints to ints" not a "vector of pointers to multimaps that maps ints to ints". In anycase i would stick with the first method, know how to use effectively, use vector's reserve method, if you have to store pointers use smart pointers instead etc, etc, yada, yada.

Share this post


Link to post
Share on other sites

vector<multimap<int, int> > paths;

this is 'a vector of multimaps'


paths.push_back(new multimap<int, int>);

and this is 'a pointer to multimap' you're trying to put in that vector, so the compiler throws a hissy fit. Change the vector declaration to match and it should work... just remember to delete your multimaps when you're done and about to dismiss the vector. ^^;

Share this post


Link to post
Share on other sites
What they're saying is:

paths.push_back(new multimap<int, int> );

should be:

paths.push_back( multimap<int, int>() );

And yes, resizing the vector would automatically create new multimaps for you. In this case, I believe it makes the most sense to hold the multimap by value like this. When paths is destroyed, so will be the multimaps. As a side note, you're passing the multimap by value in this example. That means... well, this:

multimap< int , int > example_level;
example_level.insert( make_pair( 1 , 2 ) );

vector< multimap< int , int > > paths;
paths.push_back( example_level );

assert( paths[0] == example_level ); //same data? yes...
assert( &(paths[0]) != &example_level ); //same object? no...
paths[0].insert( make_pair( 1 , 5 ) ); //modify one...
assert( paths[0] != example_level ); //and same data? no longer.

Share this post


Link to post
Share on other sites
Great! Thanks everybody ;) I never thought of the pointer thingy. It's kind of late. You've all been a great help!

Share this post


Link to post
Share on other sites
Oh, by the way, just to make it clear, doing it like:
paths.push_back(multimap<int, int>())
doesn't leave me any memory leaks right?

Share this post


Link to post
Share on other sites
Quote:
Original post by moucard
Oh, by the way, just to make it clear, doing it like:
paths.push_back(multimap<int, int>())
doesn't leave me any memory leaks right?


Correct. "multimap< int , int >()" creates a temporary, nameless variable of the multimap type. paths.push_back( ... ) then creates a new multimap inside the vector, from the temporary variable. push_back returns, and the temporary variable is then destroyed.

It's a lot like:

float x = 3.5f;
float y = int(x) + 1.0f;
//y ~ 4.0

In which case, a temporary, nameless variable of type int is created from the floating point x. 1.0 is then added to this temporary, and the results stored in y, at the temporary integer is destroyed*.

*I actually don't remember if it's destroyed right after the two numbers are added together, or after the end of the entire line... but, it dosn't matter for this case :-).

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!