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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,4f316de357ae35e9 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-08-15 12:23:08 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!sn-xit-06!sn-post-01!supernews.com!corp.supernews.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: FAQ and string functions Date: Thu, 15 Aug 2002 14:24:04 -0500 Organization: Posted via Supernews, http://www.supernews.com Message-ID: References: <20020730093206.A8550@videoproject.kiev.ua> <4519e058.0207300548.15eeb65c@posting.google.com> <20020731104643.C1083@videoproject.kiev.ua> <4519e058.0208010629.5e6182ca@posting.google.com> <20020801194720.Q1080@videoproject.kiev.ua> <4519e058.0208020605.5ab7e092@posting.google.com> <3D4AAF63.72782659@san.rr.com> <3D4B2382.7030209@telepath.com> <3D4B2ACD.FDA29B9A@san.rr.com> <3D4B401E.3060802@telepath.com> <3D4B4477.500088B@san.rr.com> <3D4EA1AC.80D17170@san.rr.com> X-Newsreader: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3719.2500 X-Complaints-To: newsabuse@supernews.com Xref: archiver1.google.com comp.lang.ada:28073 Date: 2002-08-15T14:24:04-05:00 List-Id: Stephen Leake wrote in message ... >"Randy Brukardt" writes: > >> In any case, as with many other "containers" issues, I don't see the >> point. There is no advantage to even having a "unbounded arrays" >> package, as an access to an array works fine, and there is little >> advantage to the package (only an avoidance of memory leaks, easy to >> avoid in this case). > >I disagree. There are many little details about containers that you >have to get right, and I prefer to just get them right once, and test >them just once. This is certainly true, but in many cases, it occurs because you are building a general purpose library rather than something for a specific use. That is certainly true in Claw, I'd say about 1/3 of the code is "protection against user errors" which is simply not included in code created for a specific use (and need not be). >Since I wrote the SAL containers, I have reused them many times, and >been very pleased that I did not have to rewrite and retest them. >There are 852 lines (comments and whitespace included) in >SAL.Poly.Lists.Double; that's big enough to be worth saving and >reusing. But how much of that do you actually use in your apps? My uses of lists generally use only a handleful of operations: Declare the types (four lines specifically for the list); Iterate (one line plus loop), Allocate/insert at head (one line), Deallocate all (five lines), and (more rarely) Insert at specific location or tail (seven lines). Only the last is at all complicated. (Note that access to the items is not included, because .all is automatically inserted by Ada -- so it includes no code whatsoever.) I doubt that any list package is going to save any effort here, particularly because it complicates the access to the items so severely. I want to make it clear that this does *not* apply to more complicated containers like Maps, which I would probably use if I had them. >People should be aware of data structures, but I feel they should not >have to recreate them; they should be able to reuse them. I disagree. This is the same principle as knowing how to divide numbers (it is *not* pushing the divide key on your calculator) and knowing about assembler/machine language (so that programmers have an understanding of what is expensive and what is cheap). Everyone needs to know how to recreate them; its important to know how they are implemented in order to choose the best one for the job. ... >> But I suppose I am getting to be an old fuddy duddy in this way. I >> recall thinking how annoying old programmers were when I first >> started working on Janus/Ada; now (nearly 22 years later), I sound >> like them. Sigh. Probably should go bag groceries. :-) > >No need to go that far. Just alow us to disagree :). I might allow that. :-) Randy.