From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_00,TO_NO_BRKTS_FROM_MSSP autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,a644fa9cd1a3869a X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-11-10 08:47:43 PST Path: archiver1.google.com!news2.google.com!news1.google.com!newsfeed.stanford.edu!newsfeed.berkeley.edu!news-hog.berkeley.edu!ucberkeley!nntp-relay.ihug.net!ihug.co.nz!out.nntp.be!propagator-SanJose!in.nntp.be!newsranger.com!www.newsranger.com!not-for-mail Newsgroups: comp.lang.ada From: Ted Dennison References: <3BECA3B7.5020702@telepath.com> Subject: Re: List container strawman 1.2 Message-ID: <3ScH7.20083$xS6.32546@www.newsranger.com> X-Abuse-Info: When contacting newsranger.com regarding abuse please X-Abuse-Info: forward the entire news article including headers or X-Abuse-Info: else we will not be able to process your request X-Complaints-To: abuse@newsranger.com NNTP-Posting-Date: Sat, 10 Nov 2001 11:46:55 EST Organization: http://www.newsranger.com Date: Sat, 10 Nov 2001 16:46:55 GMT Xref: archiver1.google.com comp.lang.ada:16222 Date: 2001-11-10T16:46:55+00:00 List-Id: 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.