Re: GCC 4.0 Ada.Containers Cursor danger.

["Randy Brukardt" <randy@rrsoftware.com>]

"MMM" <terekhov@emc.com> wrote in message
news:1121134291.379399.79460@z14g2000cwz.googlegroups.com...
> Georg Bauhaus wrote:
...
> > First, Ada.Containers is not trying to approximate some notions
> > from linear algebra ("orthogonal normal basis"), metaphorically
> Note that this notion is not limited to linear algebra and I'm not
> agitating
> for implementation of this notion in Ada.Containers in any way!
> ;):);):)
> What I've ment is that library should implement all commonly used and
> accepted abstractions and then, if it is practical, implement all
> needed specialisations, mixtures, etc.

Ada.Containers does implement the widely-used abstractions (Vectors, Lists,
Sets, Maps), and a number of flavors of each. What it doesn't try to do is
implement *every* possible abstraction; there isn't enough manpower to do
that. Especially nearly useless ones like unordered maps and sets.

If you think that unordered sets and maps are useful, go ahead and design
some (you'll find they fit it the design very well).

...
> Actually current proposal have to justify the use of such a
> wonderful abstractions as Ordered_Sets, Hashed_Sets, Hashed_Maps and
> Ordered_Maps as a basic set of abstractions.

We don't; they're not "basic" abstractions. They're *useful* abstractions.
We hope that in the future a fuller library is built around this one.

...
> > Indeed, a close correspondence of order and choice of container
> > will defeat some generic algorithms.
> Care to provide an example of such a generic algorithm? If your
> algorithm is so generic that order and access details are not
> important, then express you algorithm in terms of Abstract_Collection.
> Then averyone could choose any collection type that fits the task
> in question most.

We didn't define an abstract collection because it doesn't work with the
generic design of the libraries. And you have to know the element type in
order to do anything useful.

One idea that was considered was a number of signature generics that
provided such a generic container. But there is a problem with Ada that we
were not able to solve that prevents such generics being declared in the
containers packages. So we decided to leave that also for a future standard.

...
> The sad thing is that this proposal
> forces the whole Ada comunity to learn the hard way and to reinvent
> collections from scratch. Take a look at others languages collections
> implementations.

We did. Remember that the entire Ada community was involved with this
design; there are literally hundreds of comments on the library, many of
which caused significant changes to it.

The truly sad thing is that *you* didn't participate in that discussion
(which has been going on for years, including here). Now that the standard
is getting its final polishing, someone jumps in and says "I don't like
it!". Sorry, but we're not going to start over because one person who didn't
even pay any attention doesn't like it.

And let me make it very clear -- no one is completely happy with this
library. Everyone has something that they would do different. That's a
typical reaction to something that is understood by everyone. The benefit
here is having something standard. What exactly it is doesn't matter much.
It is very similar to the situation with Unbounded_Strings. That library is
designed about as incorrectly as possible, but it still gets wide use, and
it still is very valuable to Ada programmers. The exact details don't
matter.

> >> Another silliness is overgeneralization of the
> >> 'iterrator' concept and renaming it to 'cursor'.

We certainly don't have to repeat mistakes made in other libraries! An
iterator is something that actively moves from element to element. There is
no possible way for a piece of data alone to be an iterator. One could argue
that the combination of the cursor object and the Next function compose an
iterator, but not the separate pieces.

We selected the name "cursor" because it didn't have the baggage of
"reference" or "designator". A cursor is a designator to an element in a
container. Period. Yes, you can use it for iteration, but that is just one
of the possible uses for it (and not a particularly important one, IMHO).


> Authors of this proposal stated that
> they model their library on STL. So why to name the same thing
> differently?

Because the STL got it wrong. And, in any case, our terminology has to match
that of Ada, not that of C++. If we're just copying C++, there is no reason
to bother - we might as well just turn out the lights here in Adaville.

...
> It looks like the authors of this proposal didn't have a
> goal of creating clear and solid foundation for future library
development.

That was a secondary goal at best. I think we did a fine job of that, but
only attempts to add units to the containers library will show that for
sure.

> It looks like they provided just a bunch of special case algorithms and
> abstractions using far from perfect terminology.

No, we took a minimalist approach and defined only the containers that are
widely needed. That means some of the basic abstractions (which are not
going to be used much) are left out.

> To understand this one need
> no degree in mathematics, just look around - STL,Java,Python, etc.,etc.

Those libraries are far larger, and for the most part, far less rigourously
defined. Most are defined by an implementation rather than a standard. If we
had an unlimited budget, I'm sure that many more containers would have been
included. But we don't have an unlimited budget or unlimited time.

                          Randy Brukardt.