Page 1 of 1

Passing a Pointer as a Reference, Deallocating SDL2 objects

Posted: Mon Jul 27, 2015 11:28 pm
by corey__cakes
So I have a big question. I'm using C++ with SDL2 and I want to know if I can pretty much do this without any damage:
#include<SDL.h>
 
//Creates an SDL Texture in a very unefficient manner
SDL_Texture* CreateTexture(SDL_Renderer*& render, int width, int height) {
    //Create and fill a surface
    SDL_Surface *s = SDL_CreateRGBSurface(0, width, height, 32, 0, 0, 0, 255);
    SDL_FillRect(s, NULL, SDL_MapRGB(s->format, 255, 255, 255)); //makes it all white
    
    //Create texture from surface
    SDL_Texture *t = SDL_CreateTextureFromSurface(render, s);
    
    //Free the surface
    SDL_FreeSurface(s);
    
    return t;
}

int main(int argc, char** argv) {
    //Make a window and renderer
    SDL_Window* window = SDL_CreateWindow("Window", SDL_WINDOWPOS_CENTERED, SDL_WINDOWPOS_CENTERED, 200, 200, SDL_WINDOW_SHOWN);
    SDL_Renderer* render = SDL_CreateRenderer(window, -1, 0);

    //Get a texture going, make it blue!!
    SDL_Texture* t = CreateTexture(render, 200, 200);
    SDL_SetTextureColorMod(t, 0, 0, 255);

    //Draw texture to renderer
    SDL_RenderCopy(render, t, NULL, NULL);
    
    //Show the rendererererer
    SDL_RenderPresent(render);
    
    //Hold on for enough time to see it
    SDL_Delay(5000);
    
    //Destory everything
    SDL_DestroyTexture(t);
    SDL_DestroyWindow(window);
    SDL_DestroyRenderer(render);
    
    return 0;
}
The CreateTexture function uses SDL_CreateTextureFromSurface() instead of SDL_CreateTexture() because I haven't found a good description or explanation that can describe it to me (I am far from a computer scientist).

If I pass the renderer object through the CreateTexture function, does it destroy the reference at the end of the function or when I destroy it at the end of main()? Does it matter if I replace *& with *?

I'm sorry if the answer is super obvious, but I am super paranoid when it comes to my programs leaking memory or not freeing up the memory.

Thanks

Re: Passing a Pointer as a Reference, Deallocating SDL2 obje

Posted: Tue Jul 28, 2015 12:27 pm
by Nokurn
In this context, using a reference to a pointer is somewhat senseless, possibly even unsafe, unless you intend to assign the render variable inside CreateTexture and want the new value to apply to the render variable inside main. When using a library written in C, the objects won't destruct when they go out of scope--they will only be destroyed when you explicitly choose to do so via the appropriate destructor function.

Re: Passing a Pointer as a Reference, Deallocating SDL2 obje

Posted: Tue Jul 28, 2015 6:12 pm
by dandymcgee
corey__cakes wrote: If I pass the renderer object through the CreateTexture function, does it destroy the reference at the end of the function or when I destroy it at the end of main()? Does it matter if I replace *& with *?
When you pass a pointer you're not making a copy of the object, you're making a copy of the pointer (which is just an integer holding the memory address of the object). That's the purpose of pointers. They're small, fast to copy, and eliminate the need to copy large objects a bunch of times.

When the function goes out of scope, the copy of the pointer is destroyed (again, it's just an integer on the stack; whereas the thing it points to (in this case the "SDL_Renderer") is dynamically allocated memory on the heap which needs to be freed at some point). So you don't need to "free" the pointer, but you still need to free "render" in main(), which you're already doing with SDL_DestroyRenderer(render).

Re: Passing a Pointer as a Reference, Deallocating SDL2 obje

Posted: Fri Jul 31, 2015 9:49 am
by corey__cakes
dandymcgee wrote:When the function goes out of scope, the copy of the pointer is destroyed (again, it's just an integer on the stack; whereas the thing it points to (in this case the "SDL_Renderer") is dynamically allocated memory on the heap which needs to be freed at some point). So you don't need to "free" the pointer, but you still need to free "render" in main(), which you're already doing with SDL_DestroyRenderer(render).
So that means that the way I have it is safe? Or if I changed *& to just * then I'd be okay?

Re: Passing a Pointer as a Reference, Deallocating SDL2 obje

Posted: Sat Aug 01, 2015 12:43 pm
by YourNerdyJoe
corey__cakes wrote:Or if I changed *& to just * then I'd be okay?
yes

Re: Passing a Pointer as a Reference, Deallocating SDL2 obje

Posted: Mon Aug 03, 2015 4:58 pm
by dandymcgee
corey__cakes wrote:
dandymcgee wrote:When the function goes out of scope, the copy of the pointer is destroyed (again, it's just an integer on the stack; whereas the thing it points to (in this case the "SDL_Renderer") is dynamically allocated memory on the heap which needs to be freed at some point). So you don't need to "free" the pointer, but you still need to free "render" in main(), which you're already doing with SDL_DestroyRenderer(render).
So that means that the way I have it is safe? Or if I changed *& to just * then I'd be okay?
Both. The way you have it is safe but unnecessarily complex. Just use a normal pointer (*).

Re: Passing a Pointer as a Reference, Deallocating SDL2 obje

Posted: Wed Aug 19, 2015 12:16 am
by Falco Girgis
I would argue the way he has it is NOT safe, considering the createTexture() function could easily modify the Renderer pointer passed to it and fuck everything up. It has no business fucking with that pointer, so receiving the pointer by value rather than by reference is far safer if he's not using a const reference.

Re: Passing a Pointer as a Reference, Deallocating SDL2 obje

Posted: Sat Aug 22, 2015 9:55 am
by dandymcgee
Falco Girgis wrote:I would argue the way he has it is NOT safe, considering the createTexture() function could easily modify the Renderer pointer passed to it and fuck everything up. It has no business fucking with that pointer, so receiving the pointer by value rather than by reference is far safer if he's not using a const reference.
Very true, and an excellent point against this method.