Re: Allegro Wrapper Concerns

new topic     » goto parent     » topic index » view thread      » older message » newer message
Icy_Viking said...

Hi all,

As I am starting on wrapping an allegro wrapper using the new ffi.e, I have come across a few issues that are sorta bothersome, but not a huge deal in the grand scheme of things. Though I was wondering if anyone had any thoughts on this. I want to keep the allegro as close to the C source as possible. For example color.h would be color.e and contain the functions found in color.h, but of course wrapped as Euphoria functions.


AS you can see, I can keep the flags in the color.e, but ideally I would like to have the functions in there too. When I tried to run it, I got an error saying the 'all' variable could not be found. So I put the color functions in the main allegro.e and it worked. If there's any tips or tricks I can use, I'd sure like to know them.

ChrisB said...

Try (just for the sake of elimination and experimentation) defining 'all' before including color.e

This is a good example of how to the scoping rules work in Euphoria and why we have both export and public. There are technically twelve scopes inside the interpreter but we're only concerned with four:

Keyword Description
none local to the file
global global across all files
export visible to anyone that includes the file
public visible to any file that includes it, or via "public include"

You can't see export constant all because you're not including base.e in color.e. The behavior you're expecting is produced by global which is technically deprecated.

The best practice here would be to use public for symbols required for using the API like al_get_allegro_version() and use export for symbols required for implementing the API like the constants created by define_c_func(), etc.

To put it another way, anything the end-programmer needs to see should be public and anything the library-wrapping programmer needs to see should be export. I hope that makes sense.

That being said, I recommend simply following the existing file hierarchy already established by Allegro using public include in allegro5/allegro.e:


namespace allegro 
public include allegro5/base.e 
public include allegro5/color.e 
-- etc. 

And then put your open_dll() in base.e and segment your define_c_func/proc constants into their respective files:


namespace allegro_base 
include std/ffi.e 
include std/machine.e 
-- export scope is only available to files that directly include this file so this won't 
-- be available if you only include allegro5/allegro.e (which is what we want anyway) 
export constant liballeg = open_dll( "allegro-5.2.dll" ), 
    _al_get_allegro_version = define_c_func( liballeg, "+al_get_allegro_version", {}, C_UINT ) 
-- "public" scope is available to files including this file or any file that "public includes" this file 
public function al_get_allegro_version() 
   return c_func( _al_get_allegro_version, {} ) 
end function  


namespace allegro_color 
include std/ffi.e 
include std/machine.e 
include allegro5/base.e -- provides exported constant liballeg 
export constant AL_ALLEGRO_COLOR = define_c_type({ 
    C_FLOAT, -- r 
    C_FLOAT, -- g 
    C_FLOAT, -- b 
    C_FLOAT  -- a 
export constant 
    _al_map_rgb = define_c_func( liballeg, "+al_map_rgb", {C_UCHAR,C_UCHAR,C_UCHAR}, AL_ALLEGRO_COLOR ), 
    _al_map_rgba = define_c_func( liballeg, "+al_map_rgba", {C_UCHAR,C_UCHAR,C_UCHAR,C_UCHAR}, AL_ALLEGRO_COLOR ) 
public function al_map_rgb( integer r, integer g, integer b ) 
    return c_func( _al_map_rgb, {r,g,b} ) 
end function 
public function al_map_rgba( integer r, integer g, integer b, integer a ) 
    return c_func( _al_map_rgba, {r,g,b,a} ) 
end function 


new topic     » goto parent     » topic index » view thread      » older message » newer message


Quick Links

User menu

Not signed in.

Misc Menu