1. Structures in 4.0?
- Posted by ghaberek (admin) Oct 02, 2009
- 1346 views
Is there an easy (read: native) way to manage structures in memory in Euphoria 4.0? Or am I left to using peek/poke and a slew of constants plus the memory address? Note: I do not want to use any 3rd party libraries like tk_mem.e. I'd much prefer to use the included Euphoria libraries.
-Greg
2. Re: Structures in 4.0?
- Posted by jimcbrown (admin) Oct 02, 2009
- 1341 views
Is there an easy (read: native) way to manage structures in memory in Euphoria 4.0? Or am I left to using peek/poke and a slew of constants plus the memory address? Note: I do not want to use any 3rd party libraries like tk_mem.e. I'd much prefer to use the included Euphoria libraries.
-Greg
I assume you are talking about C structs. 4.0 does have some better data structure libraries (e.g. maps, sets, stacks) in the stdlib, but they aren't compatible.
4.0 does not have a C struct library as part of the stdlib. It improves the options for handling raw memory addresses but you still need to peek/poke manually.
3. Re: Structures in 4.0?
- Posted by ghaberek (admin) Oct 02, 2009
- 1322 views
Should we write something? I always thought it'd be nice to have a native structure-handling library. It would go hand-in-hand with dll.e. I mean, at least half the dll functions we link to use structures, right?
-Greg
4. Re: Structures in 4.0?
- Posted by jimcbrown (admin) Oct 02, 2009
- 1306 views
Should we write something? I always thought it'd be nice to have a native structure-handling library. It would go hand-in-hand with dll.e. I mean, at least half the dll functions we link to use structures, right?
-Greg
The ability to pass a C struct by value (rather than via a pointer) would be a huge boon to the current C interface. So would being able to take a C struct as a return value (rather than a pointer to said struct).
A native struct library should also be able to tell us the sizes of native C types (e.g. sizeof(int), sizeof(char), sizeof(short), sizeof(long)) rather than having us assume that it will always be 4, 1, 2, 4, etc.
Without these two features, I don't see the advantage of a native struct library over the existing 3rd party struct libraries.
5. Re: Structures in 4.0?
- Posted by mattlewis (admin) Oct 02, 2009
- 1328 views
Is there an easy (read: native) way to manage structures in memory in Euphoria 4.0? Or am I left to using peek/poke and a slew of constants plus the memory address? Note: I do not want to use any 3rd party libraries like tk_mem.e. I'd much prefer to use the included Euphoria libraries.
At this point, no. And it won't happen for 4.0. I've got some ideas for 4.1, however. I started a wiki page with some ideas:
http://openeuphoria.org/wiki/euwiki.cgi?SquareBracketDereferencing
Matt
6. Re: Structures in 4.0?
- Posted by ghaberek (admin) Oct 02, 2009
- 1292 views
The ability to pass a C struct by value (rather than via a pointer) would be a huge boon to the current C interface. So would being able to take a C struct as a return value (rather than a pointer to said struct).
Yes, that would be nice. Seems like it would have to be integrated into the interpreter somehow. All the structure routines I've used or written reference the memory pointer.
A native struct library should also be able to tell us the sizes of native C types (e.g. sizeof(int), sizeof(char), sizeof(short), sizeof(long)) rather than having us assume that it will always be 4, 1, 2, 4, etc.
Decoding the C_* constants is pretty simple.
function sizeof( atom c_type ) return and_bits( c_type, #FF ) end function function signed( atom c_type ) return right_shift( c_type, #1000000 ) = #01 end function function unsigned( atom c_type ) return right_shift( c_type, #1000000 ) = #02 end function function isfloat( atom c_type ) return right_shift( c_type, #1000000 ) = #03 end function
-Greg
7. Re: Structures in 4.0?
- Posted by jimcbrown (admin) Oct 02, 2009
- 1312 views
The ability to pass a C struct by value (rather than via a pointer) would be a huge boon to the current C interface. So would being able to take a C struct as a return value (rather than a pointer to said struct).
Yes, that would be nice. Seems like it would have to be integrated into the interpreter somehow. All the structure routines I've used or written reference the memory pointer.
It would. But we already have custom assembly code to manipulate the stack at arbiturary sizes. IOW, the hard part is already done, we just need to find a way to allow eu code to take advantage of it.
A native struct library should also be able to tell us the sizes of native C types (e.g. sizeof(int), sizeof(char), sizeof(short), sizeof(long)) rather than having us assume that it will always be 4, 1, 2, 4, etc.
Decoding the C_* constants is pretty simple.
Well, the size of a long will change on 64bit. Likewise, the size of an int is different on 16bit.
I was stating my preference for having machine_func()s in the interpreter that performed the sizeof() operation, rather than hardcoding constants in Eu code.
function sizeof( atom c_type ) return and_bits( c_type, #FF ) end function function signed( atom c_type ) return right_shift( c_type, #1000000 ) = #01 end function function unsigned( atom c_type ) return right_shift( c_type, #1000000 ) = #02 end function function isfloat( atom c_type ) return right_shift( c_type, #1000000 ) = #03 end function
-Greg
8. Re: Structures in 4.0?
- Posted by ghaberek (admin) Oct 02, 2009
- 1327 views
I just whipped this up. Let me know what you think. Perhaps we could polish it and include it in the 4.0 release. (I'm not sure how much testing needs to be done, or how well this actually works for that matter.)
-Greg
9. Re: Structures in 4.0?
- Posted by mattlewis (admin) Oct 02, 2009
- 1332 views
I just whipped this up. Let me know what you think. Perhaps we could polish it and include it in the 4.0 release. (I'm not sure how much testing needs to be done, or how well this actually works for that matter.)
I don't think we should include a structure library in the standard library. Here is my reasoning: Once we put something into the standard library, it probably shouldn't be removed. There are plans for adding improved native support for using raw memory structures. This is probably my (personal) highest priority for 4.1. The native support, I think, will be far superior to anything that anyone can implement in a euphoria library.
From glancing at the code, it seems reasonable. In fact, it reminds me a lot of the code used by win32lib, which has been my favorite structure library. I know that there are a few others out there, though I haven't really used them as much.
I'm actually really excited about the possibilities with enhancing euphoria to deal with raw memory. I think the approach I outlined here is a step in the right direction, but there are definitely some things that need to be worked out.
Matt
10. Re: Structures in 4.0?
- Posted by ArthurCrump Oct 02, 2009
- 1234 views
If there is any possibily of declaring structures in 4.1 using 'structures' as a keyword can 'structure' be made a reserved word in 4.0 please?
11. Re: Structures in 4.0?
- Posted by mattlewis (admin) Oct 03, 2009
- 1202 views
If there is any possibily of declaring structures in 4.1 using 'structures' as a keyword can 'structure' be made a reserved word in 4.0 please?
Yes, that's a good idea. Assuming we decide to use structure as a keyword. There hasn't really been a lot of thought put into this yet, so it's being chewed on right now.
Matt
