C structs

[Stanislav Blinov]

Lutger wrote:
> Mafi wrote:
> 
>> Hello,
>> I'm trying to write some SDL wrapper. After a long fight against
>> objconv, implib and optlink I finally got SDL loading. 

Have you tried Derelict? (dsource.org/projects/derelict). There is a 
branch called Derelict2 which is D2-compatible. Derelict does not 
require import libraries, only DLLs/SOs - it does run-time dynamic 
linking (i.e. loads dynamic library and binds function pointers at 
runtime). The only major caveat with Derelict at the moment is lack of 
proper support for 'shared' directive, which leads to chaos in 
multithreaded applications. Some work has been done to fix that, but 
much is to be done still.

>> Hurray! Now I'm going to write a wrapper for SDL_Surface. I will only use surface
>> poiters so my questions is if I can safely put these pointers into class
>> instances which on destruction free the surface (iff it's no display)?
> 
> Some caveats apply:
> 
> iirc with SDL you typically initialize and close down the different 
> subsystems. With the GC finalizing surfaces will be freed after sdl 
> shutdown, dunno if that's legal.

Generally, it's not.
Mafi, if you really want to wrap up SDL handles into classes, I'd advise 
you to either:

1) Rethink your design. For example, you could store references to all 
objects that are bound to SDL handles and free resources before 
SDL_Quit()/SDL_QuitSubSystem() call.

2) Manually 'tell' classes they should free SDL resources via some 
method. Even in C++ you'd delete all your heap-allocated objects anyway, 
so there's no difference, except that instead of calling delete you'd 
call some custom method.

Pretty much anything that concerns video in SDL should go into one and 
only thread, so you should "be doubly careful, for all manner of stupid 
mousetraps await our toes in the dark" if you think of multithreaded 
application. This means that lazy SDL resource management is in no way 
an option.

> 
> Also, sdl surfaces may take lots of space, so if possible I would free them 
> when no longer in use. The GC may not collect at all, or late. But this may 
> or may not be a problem. 

I very much like the design decision made by Eric Poggel in Yage 
(yage3d.net). This mostly concerns OpenGL resources, but generalization 
is clear enough: GL resources are allocated and initialized on demand 
(i.e. when first used) and freed if not used in some time. Similar 
approach may be taken with SDL as well, I think.