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 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 11:00:31 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!isdnet!newsgate.cistron.nl!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: List container strawman 1.2 Date: Mon, 12 Nov 2001 13:44:33 -0500 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: <9sp5ai$fr2$1@nh.pace.co.uk> References: <3BECA3B7.5020702@telepath.com> <3bef920f@pull.gecm.com> <9soq34$be6$1@nh.pace.co.uk> <3beffc62@pull.gecm.com> NNTP-Posting-Host: dhcp-200-133.miami.pace.co.uk X-Trace: nh.pace.co.uk 1005590674 16226 136.170.200.133 (12 Nov 2001 18:44:34 GMT) X-Complaints-To: newsmaster@news.cam.pace.co.uk NNTP-Posting-Date: 12 Nov 2001 18:44:34 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:16357 Date: 2001-11-12T18:44:34+00:00 List-Id: I guess if your compiler is that smart, it could be a good thing. The flag is probably not too bad a deal since it has a default. Defining equality is of questionable value/pain since the element type was private - do you want to force someone to define equality in every instance? I don't know that this would be the best answer anyway. If you have a need for unique and non-unique lists, then you've just duplicated the code anyway, so you don't save anything on the optimization - and probably lose more space along the way. If at some times you want your list object to be unique and at other times non-unique (Say, if what you are storing in the list is something the user may express a preference about) then you've got to get two lists to work with. Granted, maintaining a flag allows for the possibility that someone might be having a Blonde Moment and switch the flag back and forth causing a required unique list to have non-unique items (do you check this on state change?). There's always something getting in the way. An alternative might be to make a child of the basic list package that adds the capability. (type Unique_List is new List with private....) I would just favor making sure we have a nice simple basic list package without too many dingleberries hanging off of it so it satisfies some large percentage of the uses as simply and painlessly as possible. If there are interesting variants, it seems better to include them as children or different branches. Just my $0.02. 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/ "Martin Dowie" wrote in message news:3beffc62@pull.gecm.com... > > Well, the biggest benefit we found with this method was that it allowed > the compiler to optimise away various paths on instantiation depending on > the > parameter passed. You could always have: > > Elements_Must_Be_Unique : Boolean := False; > > The actual code difference between the two variants is very small and would > save having two package sources to maintain, which would have (almost) > exactly > the same specification. > >