Re: List container strawman 1.2

[Ted Dennison<dennison@telepath.com>]

In article <3BECA3B7.5020702@telepath.com>, Ted Dennison says...
>Changed the name of the "Iterator" type to "Index", and 
>"Passive_Iterator" to "Iterator". I'm trying out this solution before 
>taking the more drastic step of making a safe active iterator. We don't 

After sleeping on this issue, here are my current thoughts. A safe active
iterator would probably be *logicaly* more appropriate to this package, while a
faster unsafe "Index" would be more appropriate for Containers.Bounded.Lists.
However, as coded, that would completely destroy the ability to use this package
in real-time systems. Currently any use of an active iterator (eg: First, Next),
creates a new iterator, which would force dynamic allocation of a new iterator
node on the List's iterator list. 

In many (most?) real-time systems start-up heap allocations are OK, but runtime
heap operations are verboten. Again, for those unfamiliar with the issues, speed
isn't nessecarily the problem (although that may well be too). Its an issue of
time-determinism. There's just no way to tell up front how long a heap op is
going to take. It may be quite quick on average, but if we miss a deadline once,
the whole system is hosed.

This issue could be mostly fixed by changing the iterator-returning functions
into procedures. However there is another issue, which is that our theoretical
Containers.Lists.Bounded *cannot* use this method (well...I guess it could if we
limited the number of allowable iterators per List). Obviously the packages will
need to have some differences, but having different iterator/location methods
seems a smidge on the extreme side.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.