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=-2.9 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI autolearn=unavailable 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 10:53:18 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news.tele.dk!small.news.tele.dk!213.56.195.71!fr.usenet-edu.net!usenet-edu.net!enst!enst.fr!not-for-mail From: "Steven Deller" Newsgroups: comp.lang.ada Subject: RE: List container strawman 1.2 Date: Sat, 10 Nov 2001 13:50:31 -0500 Organization: ENST, France Sender: comp.lang.ada-admin@ada.eu.org Message-ID: Reply-To: comp.lang.ada@ada.eu.org NNTP-Posting-Host: marvin.enst.fr Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: avanie.enst.fr 1005418396 80088 137.194.161.2 (10 Nov 2001 18:53:16 GMT) X-Complaints-To: usenet@enst.fr NNTP-Posting-Date: Sat, 10 Nov 2001 18:53:16 +0000 (UTC) To: Return-Path: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <3ScH7.20083$xS6.32546@www.newsranger.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Errors-To: comp.lang.ada-admin@ada.eu.org X-BeenThere: comp.lang.ada@ada.eu.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: comp.lang.ada mail<->news gateway List-Unsubscribe: , List-Archive: Errors-To: comp.lang.ada-admin@ada.eu.org X-BeenThere: comp.lang.ada@ada.eu.org Xref: archiver1.google.com comp.lang.ada:16234 Date: 2001-11-10T13:50:31-05:00 > 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. Ted, I don't believe this conclusion follows. I would think the Index type could have suitable links to allow it to be "associated" with a list (probably want it to be limited private). There would also have to be handling when the object goes out of scope, to prevent dangling references, but that should be possible using controlled types. >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 necessarily 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. Same method works for bounded as well. The iterators are "bounded" only by the number of objects created by the user. Regards, Steve deller@smsail.com Smooth Sailing LLC