• Advertisement
Sign in to follow this  

std::vector of pointers

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