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,LOTS_OF_MONEY, 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-12 08:36:22 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!headwall.stanford.edu!hub1.nntpserver.com!nntp-relay.ihug.net!ihug.co.nz!out.nntp.be!propagator-SanJose!in.nntp.be!news-in-sanjose!newsranger.com!www.newsranger.com!not-for-mail Newsgroups: comp.lang.ada From: Ted Dennison References: <9sn4qm$13g29j$2@ID-25716.news.dfncis.de> <9sok8i$142am0$2@ID-25716.news.dfncis.de> Subject: Re: List container: Insert and Delete Message-ID: <8USH7.21800$xS6.33382@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: Mon, 12 Nov 2001 11:36:20 EST Organization: http://www.newsranger.com Date: Mon, 12 Nov 2001 16:36:20 GMT Xref: archiver1.google.com comp.lang.ada:16332 Date: 2001-11-12T16:36:20+00:00 List-Id: In article <9sok8i$142am0$2@ID-25716.news.dfncis.de>, Nick Roberts says... > >"Ted Dennison" wrote in message >news:Z0JH7.21323$xS6.32782@www.newsranger.com... >> Right now we are working on a defintion for *unbounded* lists, on the >> theory that this is the most basic need. Bounded is for special cases. If you >> >However, it would be nice to have an identical, interoperable, interface to >both kinds of list, no? I've been thinking over that question myself, and right now I'm not sure what the answer is. I can see two basic approaches here. Approach one is, as you say, try to create 2 List packages with identical interfaces, as near as possible. One would be "Bounded" and the other would be "Unbounded". I'll call this the Stringslib choice, as this approach is inspired by the approach taken by Ada.Strings.*. The other choice is to have separate interfaces for bounded and unbounded Lists (in this case, probably "Vectors" and "Lists" respectively) that are each designed around providing facilites that are available and efficient for the implementation in question. I'll call that the STL choice, as that's the way the STL did things. I see two main advantages to the Stringslib approach. First, it is consistent with the approach taken for the current Ada.Strings.* packages. That would hopefully make it a more natural fit into the existing Ada library. Secondly, there is only one interface to learn, so all the user has to worry about is the trade-off between flexibility and dynamic memory use, and the relative speed of typical operations in an array vs. heap environment. However, the STL approach is attractive to me for several reasons. One is that the design approach deals with abstractions rather than implementations. To me that is generally a more sound approach. Another issue is that if we make some kind of "Least Common Denominator" interface between the two implementations, one of them is going to get short-changed. For instance, an array-based "Vector" list could allow direct elment access via discrete type indices, just like an array does. Why take that away, just because heap Lists can't do it? But for the most part, I think we can delay resolving this partiular issue until we are ready to deal with Bounded lists. --- 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.