C structs

[Stanislav Blinov]

  20.10.2010 14:35, Mafi wrote:
> Am 19.10.2010 23:39, schrieb Stanislav Blinov:
>> 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.

Hm, I remember checking out trunk not so long ago. I had no trouble 
building it (though I did that on Linux). Were those errors, by chance, 
string-related? Before we completely go off-topic: you might try posting 
to Derelict forum on dsource, I'm sure this is not something that would 
be hard to fix.

>>>> 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.

Sort of, actually :)

>>
>> 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.

Things get even worse if you plan to use Derelict when it's stable, 
because the whole SDL DLL/SO may get unloaded before GC starts calling 
destructors, and you end up calling no-longer-existing functions thus 
having a (not quite so) fun time tracing bugs.

>> 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.

That's a matter of implementation, I think. For example, when 'freeing' 
surfaces that may be called upon later, you might fetch surface 
(meta)data, compress it (zlib/tga/png come to mind) and store it till 
it's required again.