Jump to content
  • Advertisement
Sign in to follow this  

std::vector of pointers

This topic is 1746 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

Hello, I have a std::vector of pointers to my Tile class:

std::vector<Tile*> m_Map;

 The tiles are added like so(depending on their id):

if(id == 0){

	Tile temp(x * 32, y * 32, solid, border);
	m_Map.push_back(&temp);
}

and when I render the tiles it does not even go to the function:

void Level::render(sf::RenderWindow& window, const sf::Vector2f& scrRegion, const sf::Vector2f& scrSize){

	//render the tile if it is on the screen
	for(auto iter = m_Map.begin(); iter != m_Map.end(); ++iter){

		(*iter)->render(scrRegion, scrSize, window); //<- does not go to the function
	}
}

I believe the problem is with (*iter)->render(scrRegion, scrSize, window). I looked online but I could not find a way to fix this. Thanks for any help.

Share this post


Link to post
Share on other sites
Advertisement

@Crusable what SyncViews says is correct and you're trying to store temporaries in a vector, but I also see something else.

Although it is harmless, you seem to be using the auto keyword in your for loop here:

	for(auto iter = m_Map.begin(); iter != m_Map.end(); ++iter){
		(*iter)->render(scrRegion, scrSize, window); //<- does not go to the function
	}

But why not go the distance, since you are already using c++11, and use a range based for loop instead of explicitly using iterators?

	for (auto tile : m_Map)
        {
		tile->render(scrRegion, scrSize, window);
	}

Isn't this the nice?

Edited by ApEk

Share this post


Link to post
Share on other sites

If you'd like to type less, simply use emplace_back member function (it's even better than moving -- it emplaces the element, i.e., constructs it directly in the container).

 

Note, however, that there are some caveats: http://stackoverflow.com/questions/13172888/is-it-safe-to-use-emplace-back-with-a-container-of-unique-ptrs

// That's why I simply used "reserve".

 

Example: http://ideone.com/2f6DNU

 

Code:

#include <cstddef>
#include <iostream>
#include <memory>
#include <vector>

struct X
{
    X() { ++count; std::cout << "Constructing, count = " << count << "\n"; }
    ~X() { --count; std::cout << "Destructing, count = " << count << "\n"; }
    
    static std::size_t count;
};
std::size_t X::count = 0;

int main()
{
    std::vector<std::unique_ptr<X>> vec;
    vec.reserve(2);
    
    // one way
    vec.push_back(std::unique_ptr<X>(new X));
    
    // another way
    vec.emplace_back(new X);

    return 0;
}

Output:

Constructing, count = 1
Constructing, count = 2
Destructing, count = 1
Destructing, count = 0

Share this post


Link to post
Share on other sites

Does emplace_back here gain any benefit over push_back for a unique_ptr by the time you have to remember to do the reserve to be exception safe?

Share this post


Link to post
Share on other sites

Mostly this: http://stackoverflow.com/questions/13172888/is-it-safe-to-use-emplace-back-with-a-container-of-unique-ptrs#comment17926086_13172922

In general, I'd say this depends on your scenario -- often, in game dev you have to preallocate anyways for performance and you know the size of your game assets in advance, so calling "reserve" is arguably already a "recommended best practice". However, there are myriad other uses of std::vector that may not fit this use case, and so you have to adjust accordingly. Such is the life of a programmer ;-)

Share this post


Link to post
Share on other sites

True I guess, but every time I really needed performance out of a vector or string I generally wanted something more like "resizeButDontInitialise" or "pushBackWithoutBoundsCheck", and generally ended up using my own thing (e.g. times when push_back became 50% of an algorithms time even with a reserve, or resize then spent 50% of its time in memset)

Edited by SyncViews

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.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!