Smart way to store records (structs)

"Mr.E" <>
18 Sep 2006 22:43:15 -0400

          From comp.compilers

Related articles
Smart way to store records (structs) (Mr.E) (2006-09-18)
Re: Smart way to store records (structs) (Tommy Thorn) (2006-09-21)
| List of all articles for this month |

From: "Mr.E" <>
Newsgroups: comp.compilers
Date: 18 Sep 2006 22:43:15 -0400
Organization: Compilers Central
Keywords: symbols, question
Posted-Date: 18 Sep 2006 22:43:15 EDT

Would someone offer suggestions as to how I should store structs for
symbol table lookup?

I haven't written anything to store structs in a symbol table because
I dont know what a good way of doing this is.

My first thought was linked list but the size of the records aren't
going to grow or shrink so that seemed useless. My second thought was
to create a pointer block containing a textual version of the record
with type and size information. I think that might work but I suspect
it will be slow. considering you have to verify the field member and
if it points to another record and another...

All suggestion are welcome.

begin record anotherType
dim s as str255
end record

begin record someType
dim abc as long
dim def as short
dim ghi as str255
dim tag as long // whats in the union
begin union
dim c as char
dim l as long
dim s as str255
end union
dim jkl as pointer to anotherType
end record

dim as long x, y, z
dim as str255 s
dim as someType test

x = sizeof( someType )
y = offsetof( s in someType )// returns the offset of field in record
y = offsetof( c in someType )// will be the same as (s in someType)
test.jkl.s = "Today is a lovely day!"

print x, y, z, test.jkl.s

[If you're OK with a fixed size symbol table, an array of structs is fine.
What's more interesting is the indexing scheme you use so that you can find
a symbol with a given name without scanning through the whole table. The
usual techniques are various forms of hashing. See Knuth, Volume 3. -John]

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.