parsing structure fields
Hi,
i´m still writing on my parser.
constructs like
myTriangle.plane.normal.x = 1.0;
are possible.
however, i´m going mad with computing the address of nested structures like this... i just can´t figure out an algorithm to perform this.
it gets even more complicated if i have
myTriangle[0].plane.normal[1] = 1.0;
or
myTriangle->plane->normal.x = 1.0;
pointers and arrays require an alternate computation method, i´m just wondering how i can pack this into one recursive algorithm... i´m getting really mad!
basically, each identifier has a base relative offset address to it´s function stack frame, and each field has it´s corresponding realitve address of i´ts enclosing structure.
data size is also known at compile time.
could someone please give some pseudo code of hoe to do this?
very very big thanks in advance!!
greets
Gammastrahöer
I'm not exactly sure what you're having trouble with. But, I would imagine you calculate the base address of the instance and then add a pre-calculated offset to it depending on what member variable is actually being referenced. For instance:
In this case, I would imagine testInner::a to have an offset of 0, and testInner::b to have an offset of 4. testInner has an overall size of 8 bytes. Now testOuter::inner would have an offset of 0, and testOuter::d would have an offset of 8.
I'm not sure if this answers your question, but let me illustrate with another example:
In this setup, testAnother:
would have an offset of 0. testAnother::outer would have an offset of 4. However, if you wanted to access say, testAnother::outer::inner::b you would have to do something like, calculate the offset of testAnother::outer (4), then the offset of outer::inner (0) and add that to the parent offset, then the offset of inner::b (4) and add that to the parent offset. So after doing that the total offset would be 8.
So assuming you had a statement like
Some pseudo code may look like this:
This assumes that the AST for a statement such as the one above has the operators as the "parents" of each pair. The leftside of the operator would be the left child, and the right side of the operator would be the subtree for the remaining portion of the statement, which could be either another identifier or another member-operator with more child identifiers.
Hope that helps!
- Jason Citron
- www.jasoncitron.net
[edited by - clash on March 5, 2004 12:58:48 PM]
[edited by - clash on March 5, 2004 1:01:25 PM]
struct testInner{ int a; int b;}struct testOuter{ testInner inner; int d;}
In this case, I would imagine testInner::a to have an offset of 0, and testInner::b to have an offset of 4. testInner has an overall size of 8 bytes. Now testOuter::inner would have an offset of 0, and testOuter::d would have an offset of 8.
I'm not sure if this answers your question, but let me illustrate with another example:
struct testAnother{ int p; testOuter outer;}
In this setup, testAnother:
![](tongue.gif)
So assuming you had a statement like
anInstance.outer.inner.b = 4;
in an AST, you would need to recursively sum the offset of the current identifier set (parent::child) with the offsets of any parent identifier sets. Maybe this would be a member variable of your compiler object, and be sure to reset it each time you begin a new identifier. Some pseudo code may look like this:
for each node in the AST if node.type is member-operator lookup offset of node.rightchild.leftchild from node.leftchild add that to the current-total-offset recurse to my right child if node.type is end-of-statement set current-total-offset to zero
This assumes that the AST for a statement such as the one above has the operators as the "parents" of each pair. The leftside of the operator would be the left child, and the right side of the operator would be the subtree for the remaining portion of the statement, which could be either another identifier or another member-operator with more child identifiers.
Hope that helps!
- Jason Citron
- www.jasoncitron.net
[edited by - clash on March 5, 2004 12:58:48 PM]
[edited by - clash on March 5, 2004 1:01:25 PM]
- Jason Citron- Programmer, Stormfront Studios- www.stormfront.com
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement