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.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00, LOTS_OF_MONEY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,fdc75443ea18fb32 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-11-29 11:37:10 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!newsfeed.direct.ca!look.ca!btnet-peer0!btnet-peer1!btnet!newsfeeds.belnet.be!news.belnet.be!psinet-eu-nl!psiuk-p4!psiuk-p3!uknet!psiuk-n!news.pace.co.uk!nh.pace.co.uk!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: Standard Queue status Date: Thu, 29 Nov 2001 14:12:37 -0500 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: <9u61b8$3o9$1@nh.pace.co.uk> References: <%QRM7.39743$xS6.65958@www.newsranger.com> <9u0qhb$pq5$1@nh.pace.co.uk> <9u0ujd$rhg$1@nh.pace.co.uk> <9u5ll7$ron$1@nh.pace.co.uk> NNTP-Posting-Host: dhcp-200-133.miami.pace.co.uk X-Trace: nh.pace.co.uk 1007061160 3849 136.170.200.133 (29 Nov 2001 19:12:40 GMT) X-Complaints-To: newsmaster@news.cam.pace.co.uk NNTP-Posting-Date: 29 Nov 2001 19:12:40 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: archiver1.google.com comp.lang.ada:17183 Date: 2001-11-29T19:12:40+00:00 List-Id: "Ted Dennison" wrote in message news:p0vN7.42577$xS6.71670@www.newsranger.com... > > I believe it was more of a "should" than a "shall" requirement. You clearly > can't entirely get rid of dynamic allocation for an "unbounded" structure. But > what you can do is try to fix it so that once the structure is "set" (no more > deletions, additions, or moves), it can be used without any heap allocations > occuring. If its feasable to do this without violating a "shall" requirement, > there is no good reason to not design it that way. > I get your point. I'd agree to reentrancy and efficiency and lack of dynamic allocation once the list is built - all of which just on general principle. Even non-realtime stuff shouldn't suffer with needless inefficiency or unpredictable behavior without good reason. Obviously, a data structure of indeterminate size has real problems for "hard" real time systems. Behavior of the code now depends on the number of elements that are there at any given run. So really, anything other than a fixed (at *compile* time) sized structure would probably be unsuitable for hard realtime. Hence, I think the requirement should be restated: The list should do allocation/deallocation of memory only to add or remove elements - not to access its contents. The list should be made as efficient and predictable as is practical for a dynamic data structure. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/