SFML community forums

Help => Graphics => Topic started by: Grimshaw on March 24, 2013, 02:30:53 am

Title: Bug in sf::RenderTexture
Post by: Grimshaw on March 24, 2013, 02:30:53 am
I think i'm not on shrooms but I just found a sick bug in SFML's code.

RenderTexture::RenderTexture() :
m_impl(NULL){}

RenderTexture::~RenderTexture(){
    delete m_impl;
}
 

I think further explanations are not needed.. The fix is easy as well!
delete m_impl;      ->          if(m_impl) delete m_impl;

Since an object of type sf::RenderTexture is not valid until a call to create, whenever an instance of it is deallocated it will cause a crash unless create was called.

Thanks!
Title: Re: Bug in sf::RenderTexture
Post by: FRex on March 24, 2013, 02:46:06 am
If you mean delete NULL; it's alright.
Quote
In C++, the definition of NULL is 0
Quote
deleting a zero pointer is harmless by definition
http://www.stroustrup.com/bs_faq2.html#null
http://www.stroustrup.com/bs_faq2.html#delete-zero
Title: Re: Bug in sf::RenderTexture
Post by: Grimshaw on March 24, 2013, 03:03:39 am
See? I'm on shrooms after all :p Sorry, I just didn't know that detail :D
Title: Re: Bug in sf::RenderTexture
Post by: Haze on March 25, 2013, 01:52:06 am
If you mean delete NULL; it's alright.
Quote
In C++, the definition of NULL is 0
Quote
deleting a zero pointer is harmless by definition
http://www.stroustrup.com/bs_faq2.html#null
http://www.stroustrup.com/bs_faq2.html#delete-zero

Huh, I didn't know that. But wasn't the point of creating the nullptr keyword in C++11 was because NULL (thus, 0) could be a valid pointer address on some obscure cases and obscure compilers? (for example, pointer to the first virtual method in a vtable, because pointer addresses can be relatives).
Title: Re: Bug in sf::RenderTexture
Post by: OniLinkPlus on March 25, 2013, 02:41:46 am
If you mean delete NULL; it's alright.
Quote
In C++, the definition of NULL is 0
Quote
deleting a zero pointer is harmless by definition
http://www.stroustrup.com/bs_faq2.html#null
http://www.stroustrup.com/bs_faq2.html#delete-zero

Huh, I didn't know that. But wasn't the point of creating the nullptr keyword in C++11 was because NULL (thus, 0) could be a valid pointer address on some obscure cases and obscure compilers? (for example, pointer to the first virtual method in a vtable, because pointer addresses can be relatives).
No, I thought it was because letting 0 be null would leave ambiguities over whether 0 should be an integer or a pointer in certain situations, e.g.  a function has two overloads, one where you can pass a pointer, and the other where you can pass an integer.
Title: Re: Bug in sf::RenderTexture
Post by: Laurent on March 25, 2013, 07:51:56 am
It's indeed because of the ambiguity. nullptr, NULL or 0 are all the zero value after compiling, and they will all produce the same runtime behaviour. The "name" of the null pointer is just a language issue.