Re: sdl2 and ffi

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

What are you doing here?

18 object event = allocate_struct(event)

I'm not sure that going to work. I had discussed the current "correct" approach here: https://openeuphoria.org/forum/137153.wc

ChrisB said...

Whats the ffi.e equivalent of allocate, as in

atom rect = allocate(16)
poke4(rect,{50,50,100,100})

The prototype currently works like this:

-- RECT structure (windef.h) 
-- https://learn.microsoft.com/en-us/windows/win32/api/windef/ns-windef-rect 
constant C_RECT = define_c_type({ 
    C_LONG, -- left 
    C_LONG, -- top 
    C_LONG, -- right 
    C_LONG  -- bottom 
}) 
 
atom rect = allocate_struct( C_RECT ) 
poke_type( rect, C_RECT, {50,50,100,100} ) 

But I'd like to rename define_c_type() to define_c_struct() and then add define_c_union(), and then re-implement define_c_type() for "raw" types (like C_STRING as a copy of C_POINTER).

-- RECT structure (windef.h) 
-- https://learn.microsoft.com/en-us/windows/win32/api/windef/ns-windef-rect 
constant C_RECT = define_c_struct({ 
    {C_LONG,"left"}, 
    {C_LONG,"top"}, 
    {C_LONG,"right"}, 
    {C_LONG,"bottom"} 
}, "RECT") 
 
atom rect = allocate_struct( C_RECT, {50,50,100,100} ) 
? peek_member( rect, "RECT.left" ) -- prints 50 
? peek_member( rect, "RECT" ) -- prints {50,50,100,100} 

Thoughts/opinions on this design are welcome.

-Greg

Hmm, that'll take some digesting, but my initial thought is that it needs to be as simple as possible to fit the eu ethos, so that someone like me can make stuff with the simpler stuff, and someone like you can do the more brain strangling spaghetti stuff.

so,

rect = allocate(16) allocates a block of memory of 16 bytes 
poke4(rect,{50,50,100,100}) - poke 4 4-byte integers into memory whose location begins at rect 

replace by
create a structure containing the following memory elements

constant C_RECT = define_c_type({            --this c_type is made up of 4 C_LONGs 
    C_LONG, -- left                          --could be any other mix of c_types 
    C_LONG, -- top                           --even other pointers to strings 
    C_LONG, -- right 
    C_LONG  -- bottom 
})\\ 

then

atom rect = allocate_struct( C_RECT )         --allocate a memory block of the size required to hold the c_type C_RECT 
poke_type( rect, C_RECT, {50,50,100,100} ) 
poke type( rect - pointer to where the memory is located 
           C_RECT - the definition of the structure elements 
           {50,50,100,100} - what to poke into each of those memory elements. 

and you could access that structure in the same way with peek as before

peek4u(rect) (= 50) 
peek4u(rect + 12) (= 100) 
peek4u({rect,4}) (= {50,50,100,100}  ) 

or is there a newer way to do that too?

Then you add define_c_struct to short circuit the above process

constant C_RECT = define_c_struct({                               C_RECT is the structure defined 
    {C_LONG,"left"},                                              these are the elements of the structure 
    {C_LONG,"top"},                                               they are named for convenience of access 
    {C_LONG,"right"}, 
    {C_LONG,"bottom"} 
}, "RECT")                                                        this is the variable we are defining with 
}}}                                                                  the structure of C_RECT 
 
Now we are going to create a block of memory that will allow the above structure to live in it 
{{{ 
atom rect = allocate_struct( C_RECT, {50,50,100,100} ) 
which we could still access with
peek4u(rect + 12) (= 100) 
peek4u({rect,4}) (= {50,50,100,100}  ) 

or

? peek_member( rect, "RECT.left" ) -- prints 50 
? peek_member( rect, "RECT" ) -- prints {50,50,100,100} 

I can see the advantages, even though it looks more messy to me, and may not be intermediate level concept wise. However, I also like the simpler version, so

define_c_type
allocate structure

is simpler than

define_c_struct
allocate_struct

Both methods produce the same end results, the second method has more frills, which IMHO increase the complexity. It's a shame you have to wrap the definitions in quotes.

If a union is an amalgamation of single items and structures, I take it it would look something like this (in simple form)

C_RECT already defined as above 
 
constant C_THING = define_c_union { 
          C_LONG, 
          C_LONG, 
          C_POINTER, 
          C_RECT,                         --pointer to the C_RECT structure 
} 
thing = allocate_union(C_THING) 
 

Just my confused thoughts.

Chris

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

Search



Quick Links

User menu

Not signed in.

Misc Menu