1. RE: Handling Structured Memory
> Yes Irv, I was only addressing the structed RAM issue and not the other
> issue of strucured data. I agree that Euphoria would be enhanced if it
> supported both concepts at the syntax level. The current method of
> assigning
> sequence element indexes to constants and then using these is a little
> kludgy.
> struct sequence CustRecord
> sequence Name
> sequence Address
> sequence Telephone
> end struct
>
> CustRecord TempCust
>
> TempCust.Name = "Derek Parnell"
> TempCust.Address = "123 Main St"
> TempCust.Telephone = "555 5555"
Thats funny =) almost very close to what mine looks like. But you have
to declare the storage size...
constant -- (integers)
NAME = struct_member(),
ADDRESS = struct_member(),
TELEPHONE = struct_member()
integer CUSTRECORD
CUSTRECORD = define_struct({
{ NAME, BYTE, 50 },
{ ADDRESS, BYTE, 50 },
{ TELEPHONE, BYTE, 50 }
})
atom TempCust
TempCust = struct( CUSTRECORD )
struct_set( TempCrust, NAME, "Derek Parnell" )
struct_set( TempCrust, ADDRESS, "123 Main St" )
struct_set( TempCrust, TELEPHONE, "555 5555" )
...
Oh well, maybe I can figure out a way to make it dynamic... hmmm
2. Re: RE: Handling Structured Memory
Hi Don,
this is my very point. Many people have written their own structured data
routines. I've written at
least two! Its a pity that such a common need is mainly met by re-inventing the
wheel. If it was
implmented inside Euphoria then we could all share the same code, and learn the
same code, much more
easily.
14/11/2002 8:00:07 AM, Don Phillips <EuNexus at yahoo.com> wrote:
>
>> Yes Irv, I was only addressing the structed RAM issue and not the other
>> issue of strucured data. I agree that Euphoria would be enhanced if it
>> supported both concepts at the syntax level. The current method of
>> assigning
>> sequence element indexes to constants and then using these is a little
>> kludgy.
>
>
>> struct sequence CustRecord
>> sequence Name
>> sequence Address
>> sequence Telephone
>> end struct
>>
>> CustRecord TempCust
>>
>> TempCust.Name = "Derek Parnell"
>> TempCust.Address = "123 Main St"
>> TempCust.Telephone = "555 5555"
>
>Thats funny =) almost very close to what mine looks like. But you have
>to declare the storage size...
>
>constant -- (integers)
>NAME = struct_member(),
>ADDRESS = struct_member(),
>TELEPHONE = struct_member()
>
>integer CUSTRECORD
>CUSTRECORD = define_struct({
> { NAME, BYTE, 50 },
> { ADDRESS, BYTE, 50 },
> { TELEPHONE, BYTE, 50 }
>})
>
>atom TempCust
>TempCust = struct( CUSTRECORD )
>struct_set( TempCrust, NAME, "Derek Parnell" )
>struct_set( TempCrust, ADDRESS, "123 Main St" )
>struct_set( TempCrust, TELEPHONE, "555 5555" )
>
>...
>
>Oh well, maybe I can figure out a way to make it dynamic... hmmm
BTW, I left my "example" code to feel a bit more like Euphoria. That is,
non-fixed size fields. An
extention to be able to optionally create fixed-size fields would be another
good idea IMO.
Maybe along the lines of...
struct sequence Address
sequence Addr1(30)
sequence Addr2(30)
sequence Addr3(30)
sequence City(20)
sequence ZIP(15)
sequence Country(2)
end struct
struct sequence CustRecord
sequence Name(50)
Address Mailing
Address Business
sequence Telephone(20)
end struct
TempCust.Mailing.Addr1 = "Level 1"
TempCust.Mailing.Addr2 = "123 Main St"
TempCust.Mailing.City = "Melbourne"
TempCust.Mailing.ZIP = "3004"
TempCust.Mailing.Country = "AU"
TempCust.Business = TempCust.Mailing
---------
Cheers,
Derek Parnell
ICQ# 7647806
3. RE: Handling Structured Memory
> Have you looked at structs.e Don?
> It's almost identical syntax.
>
> Chris
Actually yes I did. I was very impressed. Its a very good example of
structured programming imo. Only thing I didnt like about it was the
use of strings (structures) as the member items.
ie:
RGBQUAD = define_c_struct({
{ "Red", BYTE, 1 },
{ "Blue", BYTE, 1 },
{ "Green", BYTE, 1 },
{ "Reserved", BYTE, 1 }
})
Very very close to the same thing. But mine uses integers in place of
your strings. In the example above, it would take 112 bytes of memory
(I think), where mine takes 48. Around a 42% improvement. Plus
searching for an integer is mucho faster than string searching.
Just a difference of opinion. If it gets the job done the underlying
method matters not.
Don
4. RE: Handling Structured Memory
> Yes, strings are slower to search than integers, but I've never noticed
> a difference. Also if I were concerned with speed, I would use David
> Cuny's c-structure library. It's about as fast as yer gonna wrapr
> c-struct manipulation, without just doing it all manually, at low level.
>
> But I've always had a difficult time using it, so I prefer the slower
> method. I've never had a problem. There are numerous quite a few
> projects that have used structs.e.
Thats Euphoria at work =) Just make it work, Euphoria will worry about
the speed :P
> The use of strings was a choice, in order to allow easily nested
> structures, and a matter of readability, and the definitely lack of
> need, for excess constants.
>
> Integers are also used, for nested structs.
>
> And a structure definition is only ever created once, and then
> referenced. Whatever size is spent on the definition is minimal.
Yeah same here...
> I haven't seen your lib, so I can only speculate, but I assume, that
> your structs must be accessed at each nesting level, instead of directly
>
> with one call.
Actually that assumption is incorrect...
> structs.e allows you to do this..
> ----------------
> constant NAME = define_c_struct({
> {"fname", LPSTR, 1},
> {"lname", LPSTR, 4}
> })
>
> constant CLIENT = define_c_struct({
> {"id", LONG, 1},
> {"name", NAME, 1}
> })
>
> atom client client = alloc_struct(CLIENT)
> poke_struct(client,{"name","fname"},poke_string("Fred"))
>
> ----------------
> It's definitely slower than some of the other solutions, but it's a
> rounded solution.
>
> Chris
constant
X = define_member(),
Y = define_member(),
P1 = define_member(),
P2 = define_member()
constant
POINT = define_struct({
{ X, DWORD, 1 },
{ Y, DWORD, 1 }
})
constant
RECT = define_struct({
{ P1, POINT, 1 },
{ P2, POINT, 1 }
})
constant
NAME = define_struct({
{ X, BYTE, 50 } <<-- X used twice
})
constant Point = struct(POINT)
constant Rect = struct(RECT)
constant Name = struct(NAME)
struct_set( Point, X, 10 }
struct_set( Rect, {P1,Y}, 6 )
struct_set( Name, X, "Fred" )
...
Don
5. RE: Handling Structured Memory
> This means you have to define your constants within you current lib, or
> face namespacing. In order to avoid namespacing, you have to uniquely
> name your elements, meaning you can't conform to the wrapped originals
> very easily.
Yeah, name spacing *could* be an issue. So far I have yet (besides
using strings) to figure that one out to any good degree. I was
thinking I would have the exact same names as the API but all in upper
case and append an underscore. I dont think many people would have
variables like that... never can tell though.
> Don't get me wrong. I'd like to know how yours works. If it's better
> than structs.e than maybe it will end up in my arsenal.
Shoot me an email some time, its easy enough to find. I will send you
the code. I must warn you, its not an easy read. Nested structures and
all :/
If anythings unclear (prolly the whole thing LOL) I will explain it with
a couple of neat diagrams. Actually the only tough thing was figuring
out how to reuse constants...
