SFML community forums

Help => Graphics => Topic started by: Romex on January 11, 2013, 01:41:25 pm

Title: Divide by zero in sf::RenderWindow::draw SFML 2.0
Post by: Romex on January 11, 2013, 01:41:25 pm
Hello!
In my simple button class I store textures and sprites in
std::vector< std::pair< sf::Sprite , sf::Texture > > states;
It works, but some times i've got this:
Unhandled exception at 0x0f6d2382 in D_D.exe: 0xC0000094: Integer division by zero.
on
 target.draw(  states [ pos ].first, states_ );
It happens when size of states > 3.  I think sprite's link to texture become not valide when std::vector reallocate his memory .

I don't want to use dynamic memory or std::vector::reserve to solve it.
Are there any other solution?

Sorry for my English :)
Title: Re: Divide by zero in sf::RenderWindow::draw SFML 2.0
Post by: eXpl0it3r on January 11, 2013, 01:53:13 pm
If you don't want to use 'dynamic memory' then, why do you use std::vector? It also allocates the objects dynamically. ;)

I would advise you against the pairing of sf::Sprite and sf::Texture. sf::Texture is a resource = heavy object and should be handled with care, while the sprite is a very light object.
But in case you really have to/want to/need to, you can simply use a std::unique_ptr:
std::vector< std::pair< sf::Sprite , std::unique_ptr<sf::Texture> > > states;

Btw having two variables with nearly the same names (states vs states_) is a bit misleading. ;)
Title: Re: Divide by zero in sf::RenderWindow::draw SFML 2.0
Post by: Romex on January 11, 2013, 02:05:52 pm
Thanks
Quote
It also allocates the objects dynamically

Yes, but it frees allocated memory itself.
Quote
Btw having two variables with nearly the same names (states vs states_) is a bit misleading.
It's my old illness/=
Title: Re: Divide by zero in sf::RenderWindow::draw SFML 2.0
Post by: kaB00M on January 11, 2013, 09:53:42 pm
Try using std::deque instead of std::vector.

With std::queue pointers to the data should stay valid as long as you only add/remove elements at the beginning and/or end. So 'push_back', for example, is safe. This is not so with std::vector. Also, pointer arithmetic with std::deque is a 'no-no'.