From: Paul Brannan <pbrannan@...>
Date: 2002-09-25T23:03:06+09:00
Subject: Re: Object-Oriented struct Model in C

On Wed, Sep 25, 2002 at 10:42:53PM +0900, William Djaja Tjokroaminata wrote:
> I have thought about this last night.  One problem with
> "outer-to-inner" is (3), with the result of a lot of "if"'s in the mark
> and free functions, which really does not support (5).  On the other hand,
> using "inner-to-outer", we need to use stack in regards to (4), but one

You don't really need references to all the inner the objects on the
stack; you could have a reference to an object that holds references to
all your inner objects.

> problem is (6).  Also, suppose the number of VALUE's is not known at
> compile time; putting a dynamic array of VALUE's in the stack will not
> help, will it?  (Ruby just detects a VALUE pointer, not an array of
> VALUE's)  Does this mean using "inner-to-outer" we have to create at

An array of VALUES allocated with ALLOCA would work, as long as it is
aligned properly on the stack.  This uses more stack space than a Ruby
Array, but is cheaper to construct.

> least a single stack/temporary VALUE variable of type Ruby Array to hold
> all those I's temporarily?  (You see how complicated it may become for any
> arbitrarily complex and deeply-nested data structure.)

It doesn't have to be an Array, though an Array would work.

Also note that if you have a structure like this:


               +-A
          Top--|
               +-B--+-C
                    |
                    +-D

Then you only need to keep references C and D on the stack while
registering B; you only need to keep references to A and B while
registering Top (since C and D are already referred to by B).

I don't think, then, that the level of nesting matters (except if you
are worried about running out of stack space); you only need be
concerned about the number of objects at any given level.

Paul