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,7ee10ec601726fbf X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-10-31 10:53:25 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!sn-xit-01!sn-post-02!sn-post-01!supernews.com!corp.supernews.com!not-for-mail From: "Matthew Heaney" Newsgroups: comp.lang.ada Subject: Re: why not Date: Wed, 31 Oct 2001 13:56:36 -0500 Organization: Posted via Supernews, http://www.supernews.com Message-ID: References: <3BC5D730.DA950CC7@boeing.com> <9q4pa7$1ad$1@nh.pace.co.uk> <3BC6ACC8.23EF21BC@free.fr> <3BC71F54.1FFE78FA@boeing.com> <1KGx7.26476$ev2.35117@www.newsranger.com> <3BC7AD82.2A0CCCD4@acm.org> <9qhiqr$af0$1@nh.pace.co.uk> <1nDC7.180$6S7.92255364@newssvr11.news.prodigy.com> <9rjsak$bp3$1@nh.pace.co.uk> <9rmhb9$o1b$1@nh.pace.co.uk> <3BDEF0FE.B55FED9E@san.rr.com> <9rmuqi$es$1@nh.pace.co.uk> <3BDF1F13.4B99361C@san.rr.com> <9rnbtv$5i4$1@nh.pace.co.uk> <3BDF8C59.5020108@mail.com> <9rp9bk$6m9$1@nh.pace.co.uk> X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Complaints-To: newsabuse@supernews.com Xref: archiver1.google.com comp.lang.ada:15498 Date: 2001-10-31T13:56:36-05:00 List-Id: "Marin David Condic" wrote in message news:9rp9bk$6m9$1@nh.pace.co.uk... > Perhaps you would agree with my proposal that a first cut at a standard > component library could start with some basic form of Lists and Maps? We could start with an unbounded, doubly-linked list, a la STL std::list. > I'd > like to see an informal adoption of a handful of packages that let the user > make lists (sorted? unsorted?) of basic data types (things like Integers, > Strings, plain vanilla records, ...) and Maps of similar items. The element type that is nonlimited and definite. (Type String all by itself would NOT be supported, because that type is unconstrained.) The container itself doesn't do sorting. (I assume there would be a separate algorithms package, that operates on iterators. That influences what iterator types look like.) Here's one idea: generic type Element_Type is private; with function "=" (L, R : Element_Type) return Boolean is <>; package Ada.Lists_Unbounded is type List_Type is private; procedure Push_Front (List : in out List_Type; Element : in Element_Type); procedure Push_Back (List : in out List_Type; Element : in Element_Type); procedure Clear (List : in out List_Type); ... type Iterator_Type (List : access List_Type) is limited private; type Constant_Iterator_Type (List : access constant List_Type) is limited private; type Reverse_Iterator_Type (List : access List_Type) is limited private; type Constant_Reverse_Iterator_Type (List : access constant List_Type) is limited private; ... end; You have to decide whether the List_Type is limited or nonlimited. The latter implies that List_Type must privately derives from Controlled. You have to decide whether the List_Type will automatically Clear itself when its lifetime ends. Your answer would influence whether List_Type is Controlled. The decision to be Controlled influences where the generic may be instantiated (say, only a library scope). Note that not automatically reclaiming memory by the list itself isn't such a bad thing, because you can include another component in the library to do this, like this: generic type Container_Type (<>) is limited private; with procedure Clear (Container : in out Container_Type) is <>; package Container_Control is type Control_Type (Container : access Container_Type) is limited private; ... end; declare List : aliased List_Type; Control : Control_Type (List'Access); begin ... use list end; When the scope ends, Control is finalized, and during its Finalization it calls Clear (Container). Not making the container types controlled will make them more efficient, but introduce the possibility for memory leaks (if the client doesn't also use a helper type, as above). Of course the containers should NOT be task safe. Threading behavior can be handled by the client himself, by combining a sequential container type with other language primitives. This is consistent with how the rest of the predefined library has been designed.