comp.lang.ada
 help / color / mirror / Atom feed
From: Maciej Sobczak <see.my.homepage@gmail.com>
Subject: Re: OO Style with Ada Containers
Date: Mon, 19 Nov 2007 13:29:28 -0800 (PST)
Date: 2007-11-19T13:29:28-08:00	[thread overview]
Message-ID: <a07c57ed-45f6-415e-932a-bb7706ddeb5d@a39g2000pre.googlegroups.com> (raw)
In-Reply-To: a13459f0-13d9-4f7d-a619-c28dd8c4e869@f3g2000hsg.googlegroups.com

On 19 Lis, 16:51, Matthew Heaney <mhea...@on2.com> 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<int>(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



  parent reply	other threads:[~2007-11-19 21:29 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-14 23:28 OO Style with Ada Containers braver
2007-11-14 23:50 ` Adam Beneschan
2007-11-14 23:59   ` braver
2007-11-15  0:24     ` braver
2007-11-15  9:36       ` Ludovic Brenta
2007-11-15 10:36         ` braver
2007-11-15 11:35           ` Ludovic Brenta
2007-11-15 13:50             ` braver
2007-11-19  2:45               ` Matthew Heaney
2007-11-15 18:22             ` braver
2007-11-15 20:18               ` Ludovic Brenta
2007-11-19  2:48                 ` Matthew Heaney
2007-11-19  2:47               ` Matthew Heaney
2007-11-19  2:39             ` Matthew Heaney
2007-11-19  2:38           ` Matthew Heaney
2007-11-19  2:36         ` Matthew Heaney
2007-11-19  2:24       ` Matthew Heaney
2007-11-23 10:28         ` braver
2007-11-23 13:29           ` Martin Krischik
2007-11-23 14:19             ` Georg Bauhaus
2007-11-25 13:38           ` Ludovic Brenta
2007-11-26  3:58             ` Matthew Heaney
2007-11-26  3:55           ` Matthew Heaney
2007-11-23 22:25         ` braver
2007-11-23 22:46           ` Pascal Obry
2007-11-23 22:52             ` braver
2007-11-26  4:09               ` Matthew Heaney
2007-11-26  4:07             ` Matthew Heaney
2007-11-26  4:03           ` Matthew Heaney
2007-11-26 13:45             ` Matthew Heaney
2007-11-26 19:09               ` braver
2007-11-26 20:29                 ` Matthew Heaney
2007-11-27 19:31                   ` Georg Bauhaus
2007-11-27 20:12                     ` Matthew Heaney
2007-11-25 14:08         ` braver
2007-11-26  4:21           ` Matthew Heaney
2007-11-19  1:04   ` Matthew Heaney
2007-11-15  8:43 ` Dmitry A. Kazakov
2007-11-15 14:04   ` Maciej Sobczak
2007-11-19  2:53     ` Matthew Heaney
2007-11-19 13:44       ` Maciej Sobczak
2007-11-19 14:44         ` Martin
2007-11-19 15:51         ` Matthew Heaney
2007-11-19 17:33           ` Markus E L
2007-11-19 21:29           ` Maciej Sobczak [this message]
2007-11-19 22:16             ` Matthew Heaney
2007-11-19 22:22               ` Matthew Heaney
2007-11-20 14:11               ` Maciej Sobczak
2007-11-20 17:00                 ` Matthew Heaney
2007-11-20 17:17                   ` Matthew Heaney
2007-11-20 21:13                   ` Maciej Sobczak
2007-11-20 21:57                     ` Matthew Heaney
2007-11-21  4:51                     ` Matthew Heaney
2007-11-21  9:18                       ` Georg Bauhaus
2007-11-21 15:59                         ` Maciej Sobczak
2007-11-21 17:41                           ` Georg Bauhaus
2007-11-21 22:25                         ` Jeffrey R. Carter
2007-11-20 18:06                 ` Georg Bauhaus
2007-11-19 16:19         ` Dmitry A. Kazakov
2007-11-19 20:45           ` Maciej Sobczak
2007-11-20  2:24             ` Matthew Heaney
2007-11-20  9:06             ` Dmitry A. Kazakov
2007-11-20 12:16               ` Georg Bauhaus
2007-11-21 15:17                 ` Dmitry A. Kazakov
2007-11-19  2:50   ` Matthew Heaney
2007-11-19  1:03 ` Matthew Heaney
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox