Do you have a question? Post it now! No Registration Necessary. Now with pictures!
- Posted on
- FAQ 4.47 How do I handle circular lists?
Re: Order of operations
Well, no. That is why software engineering principles recommend to avoid
side effects and require to document(!) those odd behaviours.
Should be spelled out in big bold red letters in the documentation.
Nope. The compiler can only guess that a side effect may occur. If it
actually does happen is unknown at compile time and therefore equivalent
to solving the halting problem.
Mabye. But it is always problematic trying to enforce best practises by
technology. It rarely works because people are very inventive when it
comes to circumventing restrictions.
Re: Order of operations (was: FAQ 4.47 How do I handle circular lists?)
Where is this defined?
Which is something I would *not* have expected and reeks strongly of
Irrelevant. Just because all implementations you have access to behave
the same doesn't mean the behaviour is defined.
Re: FAQ 4.47 How do I handle circular lists?
Not only for the less-experienced, but for *everyone* -- that
is, if you're doing a *lot* of them. Why?
Because having the one fixed-in-memory array with an index
running back and forth within it involves ZERO garbage-collection
overhead. Allocate the thing once, and it's done.
Now, if the thing has to grow from time to time, then the
push and pop ptrs (indices) (unbalanced) run into each other,
and you have to grow the array, maybe double (or some other function)
its size, do you don't do this growing (eg gc-causing) at every
In fact, write a simple fcn "verifySizeOk" (ary, desired-next-index
to use) and let it do whatever's needed as the need occurs.
Anyway, pushes are nice, but the gc's can eat you alive.
[of course, probably lists are internally allocated er grown
*already* by some such scheme!]