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.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,a3736685ef876ab2 X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews.google.com!a39g2000pre.googlegroups.com!not-for-mail From: Maciej Sobczak Newsgroups: comp.lang.ada Subject: Re: OO Style with Ada Containers Date: Mon, 19 Nov 2007 13:29:28 -0800 (PST) Organization: http://groups.google.com Message-ID: References: <1195082906.420079.195000@d55g2000hsg.googlegroups.com> <1s27rv0gt4ujj$.3e2k326rp54d.dlg@40tude.net> <60e46dc9-d8ca-4f47-9e8a-f90a7d45e752@w28g2000hsf.googlegroups.com> NNTP-Posting-Host: 85.3.98.148 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: posting.google.com 1195507769 3328 127.0.0.1 (19 Nov 2007 21:29:29 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Mon, 19 Nov 2007 21:29:29 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: a39g2000pre.googlegroups.com; posting-host=85.3.98.148; posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9,gzip(gfe),gzip(gfe) Content-Disposition: inline Xref: g2news1.google.com comp.lang.ada:18512 Date: 2007-11-19T13:29:28-08:00 List-Id: On 19 Lis, 16:51, Matthew Heaney wrote: > > Can you convince me that Ada.Containers is closer to STL than to Java > > containers (for example)? > > But the burden of proof is on you No, because I'm not convinced either way. :-) Ada.Containers can be compared to Java containers on the basis that each container from Ada.Containers (except from Indefinite_XXX, which are Ada-specific) has some analogous implementation in the java.util package. Then, considering the fact that elements in Ada.Containers cannot be modified without naming the container in addition to providing the cursor/iterator and this is different from both STL and Java (STL dereferences iterators to l-values and Java is reference-oriented anyway - in both cases iterators can be used to query as well as to update elements), then I would say that Ada.Containers has a similar "distance" to STL as it has to java.util. This metrics of "distance" is of course flawed, but the above is as good as anything else. > As I stated then: > > "This library API is modeled on the STL. It has the same containers > as > the STL does, using the same container names and semantics. I see (except for Indefinite_XXX, which are Ada-specific), but that still does not convince me. C++ does not currently have any hash containers (the "original" STL and some third-party implementations might have them, though) and it has one more very useful sequence: deque. Plus some adaptors like stack or queue and priority_queue. Not mentioning multimap and multiset. The ecosystem of containers is much wider in C++. No, I don't think it qualifies for "it has the same containers". Rather "you might find similarities". > If you > know > the STL already then you will instantly understand how this library > works. This is true. Same if you come from Java. :-) The point is that Vector, Doubly_Linked_List or Hashed_Map are not names reserved for STL - these are basic CS concepts, known to everybody and everywhere. There is nothing "STLish" in them. > It does not have any of the STL algorithms, but that's only > because I wanted to keep the API small (and not because it's not > possible to support STL-style algorithms -- it is). The API described > here has exactly the minimum set of containers I believe all Ada > developers need, in exactly the form they need it." I understand it. > > Do you by any chance find > > something in C++ that is worth imitating? :-) > > Yes, of course: the STL. What about IOStreams? Hey, we can even mix these two: copy(my_vector.begin(), my_vector.end(), ostream_iterator(cout, " ")); ;-) > Well, the library is modeled on the STL. There are necessarily > differences, because the languages are different, and my design > philosophy was (and is) to use Ada idioms where appropriate. I understand it. I understand that you took your knowledge of STL and with this knowledge in mind designed the Ada.Containers. Now - if you came from Java instead, do you think you would have designed something different? I doubt it. I'm convinced that by taking Java containers (they call them collections, actually), cutting off things here and there and bending everything to achieve idiomatic Ada you would come to the same result. That's why I claim that there is no STL flavor in Ada.Containers. It might have been there as a motivator, but was lost in the cutting and bending phase. > > How can I use these mechanisms to make iterator adaptors? > > A generic algorithm in Ada would look something like: > > generic > type Cursor is private; > with function Next (C : Cursor) return Cursor is <>; > with function Has_Element (C : Cursor) return Boolean is <>; > ... > procedure Generic_Algorithm (C : Cursor); You mean: read-only algorithm. What about modifying algorithms? Ada.Containers.Vectors.Generic_Sorting shows the problem. > An iterator adapter just means replacing the cursor operations for the > container with something else, e.g. > > function Return_Odd_Only (C : Cursor) return Cursor is > CC : Cursor := C; > > begin > while Has_Element (CC) > and then Element (CC) rem 2 = 0 > loop > Next (CC); > end loop; > return CC; > end Return_Odd_Only; > > procedure Algorithm is > new Generic_Algorithm > (Cursor, > Next => Return_Odd_Only, > others => <>); -- verify syntax I like it. Really. It is not possible to do it in C++, the new classes have to be composed with replaced operations. -- Maciej Sobczak * www.msobczak.com * www.inspirel.com