Public Group

std::vector of pointers

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

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 on other sites

@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 on other sites

Do they support that in DevStudio yet?

Thank you.

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 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 on other sites

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 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

• 13
• 18
• 29
• 11
• 20