C structs

[Mafi]

Am 19.10.2010 23:39, schrieb 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.
I've tried Derelict2 first. I'm using D2 so Dererelict1 was no option. 
After svn checkout (I know it could be broken but I found no 
'stable'-link) I tried to compile and got a bunch of immutability 
errors. I thought that it must be an yet uncomplete port so I went with 
static linking but I tried to write everything so I could use Derelict 
in some future.

>>> 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.
That sounds good. It isn't even reference counting.
>
> 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.
Yea, I didn't want to prevent people from using from using some close 
moethod but D has a GC included so why don't use it? Now I know it's a 
horrible idea.
>
> 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.
> [...]
> 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.
I think you can't do it with sdl. If I understood this bit right, you 
want to free resources when not used and reload them later again. A 
problem with this is that loaded-and-then-manipulated surfaces would 
loose their change and completely code generated surfaces would be 
completly lost.