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


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


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