1. RE: Handling Structured Memory
- Posted by Don Phillips <EuNexus at yahoo.com> Nov 13, 2002
- 426 views
> 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
- Posted by Derek Parnell <ddparnell at bigpond.com> Nov 13, 2002
- 449 views
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
- Posted by Don Phillips <EuNexus at yahoo.com> Nov 13, 2002
- 445 views
> 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
- Posted by Don Phillips <EuNexus at yahoo.com> Nov 13, 2002
- 418 views
> 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
- Posted by Don Phillips <EuNexus at yahoo.com> Nov 13, 2002
- 426 views
> 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...