Re: Minimizing nested structure storage...

Reply embedded.




> I was thinking of how to reduce the amount of memory needed to
> store nested structure declarations, while at the same time avoiding
> the use of tree structures.


IMHO, the use of tree structures to represent the declarations is a
bad attempt. But i am not sure how a simple hash index symbol table
with proper scope information in each symbol, can be improved upon by
your proposed approach.


> I'm planning on representing heirarchy in a flat structure. The
> symbol table will be a hash table. Each hash table entry will be a
> pointer to a sorted dynamic array that handles collisions. A modified
> binary search will be used to insert an entry if a collision occurs.
>
>
> The following type declarations...
>
> typedef struct level1_s
> {
> int a, b;
> } level1;
>
... snip


Well one of the problems that i can see with the above approach 1. The
symbol 'a' is stored into the symbol table at the end of the
declaration of that variable. that means that at "int a," <<-- the
symbol has to be stored.


2. To store it with the name of the type "level1", we would have to
wait till the end of the class declaration, i.e till } level1


3. That implies that one would have to store the symbols being
declared in the meantime in some temporary form. till the class
declaration is over.


Now for a class with a large number of data members that might prove
to be a problem. Further more consider the access of the declared
member in an expression inside the class itself.


Say in C++:


  class X{


  public:
  const static int a =1;


  int fn(int arg = a);
  };


then it might prove to be a problem.


>
> ...would be stored as...
>
> level1#a
> level1#b
>
... snip




> The following variables...
>
> level2 foo;
> level3 bar;
>
> ...would parse as...
>
> foo.c.b = 1234;
> 1) foo -> level2
> 2) c -> level2>
> 3) level2> -> level1
> 4) b -> level1#b
> 5) Emit move [address(foo) + offset], 1234
... snip


IMHO, The amount of work required to translate foo.c.b into the way
that you have described above , would be equal to ,if not more to the
normal method of accessing members by scoping changes.


Regards !
Vijay

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