   free(), delete and delete[]
  Hi i was just wondering how you find out which function (free, delete, delete[]) your suppose to use in opengl and STL functions that return by pointer. How can you tell whats been used to allocate the memory inside the function?Thanks alot,Steve   
  1: Find out if you actually own the resource you receive from a function.1a: If you do, then the API will tell you how to free the resource in the documentation.1b: If it's a reasonably sane API, you won't own it, and it will have a Release()/Free()/Destroy() function for you to call to 'free/delete' that resource. Again, this information will be in the documentation.What specific functions do you need clarification for?   ;  auxDIBImageLoad in glaux.h, got me thinking about how to actually determine if a function allocates memory in the c++ way (new/delete) or the c way (malloc)   ;None of the STL's functions return anything that you need to free yourself, if it is not something you allocated yourself in the first place (in which case, of course, you need to use the deallocation method that corresponds to the allocation method you used - this has nothing to do with the STL).With OpenGL, if you need to release something, there is always a corresponding OpenGL function that does the deed. Consult your documentation. Again, there's nothing you can or should free using free/delete/delete[] if it wasn't allocated by you in the first place.EDIT: glaux isn't OpenGL, but again, consult the function's documentation; it should tell you everything you need.   ;Quote:Original post by steveharpergot me thinking about how to actually determine if a function allocates memory in the c++ way (new/delete) or the c way (malloc)It shouldn't matter to the end user. In a sane API, this is usually accomplished by having a function which cleans it up whatever way they allocated. Example:int * AllocExample( void ) {    return new int( 42 );}void FreeExample( int * pointer ) {    delete pointer;}Then using code would use these two functions, never delete/freeing what they did not new/malloc.As with any API, you should check the documentation. For auxDIBLoadImage, I see conflicting documentation (and none from the MSDN!!) - nehe uses delete to free it's memory in chunks, whereas I'm also seeing examples using free(). Prehaps this is one of the reasons it seems that nobody uses that API anymore. Were I forced to use it, I would use free(). I base this upon the reasoning that if it's a C style API, it's more likely to use C style allocation, and thus would be best freed with the standard C memory release function, free().   ;  There is no platform independent way to detect the allocation method used ... if there was, you wouldn't have to free them differently, it would just look at the address and determine for you how to free it.It is definately a case of ... if you allocated it, you free it, unless you transfer ownership to someoneelse ... and by transfer ownership, that includes telling them when and how to delete it ...Almost no APIs transfer ownership from an API to pure C, they almost all use either an API level cleanup, or a ref counting scheme.   ;  Thanks guys, i kind of knew that the API control's the allocation/deallocation of dynamic memory. Just that function got me worried about other functions i might be using in API's that require you to do your own cleaning up. I agree with you MaulingMonkey, i used free() too. The only reason i used auxDIBLoadImage in the first place was due to laziness, and i had intentions to write my own Bitmap loading code, but wanted to get the more important parts of my application functioning efficiently first.   ;Quote:Original post by steveharperThe only reason i used auxDIBLoadImage in the first place was due to laziness, and i had intentions to write my own Bitmap loading code, but wanted to get the more important parts of my application functioning efficiently first.Now, you were going the right direction with your lazyness idea, however you then went wrong.Why are you re-writing a bmp loader?Why not use something someone else has done?There are a few loaders out there already (Corona, DevIL, my own GTL), so why not continue your lazy streak and reuse them?   ;Quote:Original post by phantomWhy are you re-writing a bmp loader?...There are a few loaders out there already (Corona, DevIL, my own GTL)That made me chuckle.   ;Quote:Original post by MaulingMonkeyQuote:Original post by phantomWhy are you re-writing a bmp loader?...There are a few loaders out there already (Corona, DevIL, my own GTL)That made me chuckle.Yeah, somedays something strikes you just right ... and I agree with you Mauling, that's just plain funny ;)   