I suppose it is better to use static memory allocation when one needs a fixed number of elements of a certain object. If so, why are most objects in SDL (including objects of the type SDL_Surface) and Allegro typically declared as pointers and allocated dynamically by functions like SDL_CreateRGBSurface()?
Static or dynamic object allocation?
Because the size of the object's data is not known at compile time or the lifetime of the objects aren't guaranteed to be FILO. There's nothing wrong with dynamically allocating memory. There is, however, problems with misusing dynamic memory, such as: Frequent allocation and deallocation of small objects (use object pooling), freeing objects that don't belong to your process's or DLL's private heap (such as attempting to free an object you obtained through a DLL boundary), and using it where stack based allocation is more appropriate.
Author
The total size of a SDL_Surface in a 32-bit system, as seen in the SDL wiki, is likely to be 60 bytes. Each pointer itself (not the data it points to) occupies 4 bytes, correct? So, is the object's size really not known at compile time?
In case you actually refer to the total size of the data pointed by the pointers within the SDL_Surface, why should the SDL_Surface object itself be allocated dynamically?
Note that one of the SDL_Surface members is a ref count. It's expected that you can extend it's lifetime by incrementing the ref count, which is hard to do if someone's allocated it on the stack.
The total size of a SDL_Surface in a 32-bit system, as seen in the SDL wiki, is likely to be 60 bytes. Each pointer itself (not the data it points to) occupies 4 bytes, correct? So, is the object's size really not known at compile time?
SDL is meant to be used as a dynamic library. They are free to add new members because of this at any time should they wish. Were it static, you'd be forced to use SDL as a static library. Among other problems, this would make it difficult or impossible to have SDL updates automatically copy with platform changes that otherwise don't require a recompilation of your application (e.g. the transition from X11 to Wayland on many Linux systems).
In case you actually refer to the total size of the data pointed by the pointers within the SDL_Surface
Never do that. There is absolutely no good reason to ever do it. If you think you're being especially clever and optimizing somehow by doing it, you're being _too_ clever and should knock it off.
In any case, you're worrying about something you don't need to worry about. If and when you find that SDL's treatment of allocation is in any way a bottleneck or performance dog then file a bug report against SDL with the proof. It's unlikely you'll have any test case like this that isn't just a result of something silly in your code (e.g., if you're allocating/deallocating surfaces during your game loop; don't do that).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
