www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - C structs

reply Mafi <mafi example.org> writes:
Hello,
I'm trying to write some SDL wrapper. After a long fight against 
objconv, implib and optlink I finally got SDL loading. 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)?
Oct 19 2010
next sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
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. 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. 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.
Oct 19 2010
parent reply Stanislav Blinov <stanislav.blinov gmail.com> writes:
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.
Oct 19 2010
parent Mafi <mafi example.org> writes:
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.

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.

 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.

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.

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.
Oct 20 2010
prev sibling parent Stanislav Blinov <blinov loniir.ru> writes:
  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.

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.


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.

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.

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.
Oct 20 2010