comp.lang.ada
 help / color / mirror / Atom feed
From: Duncan Sands <baldrick@free.fr>
To: Matthew Heaney <matthewjheaney@earthlink.net>
Cc: comp.lang.ada@ada-france.org
Subject: Re: Ada.Containers.Vectors - querying multiple elements
Date: Thu, 28 Apr 2005 15:53:02 +0200
Date: 2005-04-28T15:53:02+02:00	[thread overview]
Message-ID: <mailman.98.1114696396.24457.comp.lang.ada@ada-france.org> (raw)
In-Reply-To: <u8y33xcni.fsf@earthlink.net>

Hi Matthew, thanks for your detailed explanation.

> > When you have a container that is an extensible array, wanting to be
> > able to directly access slices of it as an array seems normal (and
> > useful) to me.
> 
> In the STL way of doing things, you don't write algorithms in terms of a
> specific container.  You write algorithms in terms of an "abstract
> container."  Iterators allow you to view a container in a
> container-neutral way, as merely a "sequence of items," described using
> an iterator pair to bound the sequence, and with iterator operations for
> navigating among the elements of the sequence.
...
> The problem you're having is that you have an algorithm written in terms
> of a specific container: an array.  And now you want to apply that
> algorithm to a different kind of container: a vector.  This is precisely
> the kind of problem the STL algorithm model was designed to solve.
> 
> You can do this in Ada too, by writing algorithms in a way that is
> container neutral.  See for example generic_anonymous_array_sort, which
> is declared like this:
...
> Had you written your algorithm as above, then you wouldn't be having the
> difficulties you're having now.  It would work for an array:
...
> Now, don't you think that's better than what you did?

You are certainly correct that when I quickly reworked the routine in
question to take a vector rather than an array, I should have done it
in a more abstract way, as in your example.  As for the other code I
have in mind, at some point things really have to be contiguous arrays
for efficiency reasons.  As pointed out in the AI discussion, efficiency
was not the main goal of the container libraries - people who need
something super efficient should write their own custom object.  That's
fine by me.

> > I guess the point is that Vector is not an extensible array - the
> > designers chose a more abstract design.
> 
> An extensible array is the model for a vector, but of course a vector
> doesn't have to be implemented that way.  

Extensible arrays are useful - it would have been nice to have them.

> You want to view the elements in a vector as a contiguous array, but
> that wouldn't confer any benefits unless if the underlying
> implementation is a contiguous array.

That's not entirely true, but in any case it would seem to go against
the philosophy you outlined above.

All the best,

Duncan.




  reply	other threads:[~2005-04-28 13:53 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-26 11:43 Ada.Containers.Vectors - querying multiple elements Duncan Sands
2005-04-26 14:12 ` Georg Bauhaus
2005-04-26 14:39   ` Duncan Sands
2005-04-26 15:44     ` Matthew Heaney
2005-04-26 16:05       ` Duncan Sands
     [not found]       ` <1114531544.32583.142.camel@localhost.localdomain>
     [not found]         ` <426E72C3.9070108@on2.com>
2005-04-26 16:59           ` Duncan Sands
     [not found]           ` <1114534751.32583.144.camel@localhost.localdomain>
     [not found]             ` <426E73DE.2070505@on2.com>
2005-04-26 17:08               ` Duncan Sands
2005-04-26 18:17                 ` Martin Dowie
2005-04-26 18:48                   ` Duncan Sands
2005-04-26 18:59           ` Duncan Sands
2005-04-26 19:05             ` Georg Bauhaus
2005-04-26 20:34               ` Duncan Sands
2005-04-26 21:47               ` Dr. Adrian Wrigley
2005-04-26 23:21                 ` Marius Amado Alves
     [not found]                 ` <9decddc0038674b3c85aeceefb4d3b83@netcabo.pt>
2005-04-27  8:15                   ` Duncan Sands
     [not found]                   ` <1114589729.10418.13.camel@localhost.localdomain>
2005-04-27 11:49                     ` Marius Amado Alves
2005-04-28  0:36                       ` Randy Brukardt
2005-04-28  7:09                         ` Duncan Sands
2005-04-27 11:10                 ` Georg Bauhaus
2005-04-27 11:57                   ` Duncan Sands
2005-04-28 14:17       ` Duncan Sands
2005-04-27  4:59   ` Jeffrey Carter
2005-04-27  7:21     ` Duncan Sands
2005-04-28  2:54       ` Jeffrey Carter
2005-04-28  7:15         ` Duncan Sands
2005-04-28 12:27           ` Matthew Heaney
2005-04-28 13:18           ` Matthew Heaney
2005-04-28 13:53             ` Duncan Sands [this message]
2005-04-29  2:46           ` Jeffrey Carter
2005-04-29 18:22             ` Robert A Duff
2005-04-28  7:18         ` Duncan Sands
2005-04-28  0:33     ` Randy Brukardt
2005-04-28  3:09       ` Jeffrey Carter
2005-04-28 20:55         ` Randy Brukardt
2005-04-29  2:54           ` Jeffrey Carter
2005-04-29 18:34             ` Robert A Duff
2005-04-29 20:18               ` Randy Brukardt
2005-04-29 20:00             ` Randy Brukardt
2005-04-30  4:06               ` Jeffrey Carter
2005-04-29  7:52           ` Dmitry A. Kazakov
2005-04-29 20:26             ` Randy Brukardt
2005-04-30  9:24               ` Dmitry A. Kazakov
2005-05-02  3:21                 ` Randy Brukardt
2005-05-02 17:04                   ` Dmitry A. Kazakov
2005-05-02 18:57                     ` Robert A Duff
2005-05-03  8:14                       ` Dmitry A. Kazakov
2005-05-03 23:30                         ` Robert A Duff
2005-05-05 10:51                           ` Dmitry A. Kazakov
2005-05-07  1:20                             ` Matthew Heaney
2005-05-07  7:17                               ` Dmitry A. Kazakov
     [not found] <1114515832.32583.41.camel@localhost.localdomain>
     [not found] ` <426E5A0B.3010109@on2.com>
2005-04-26 16:00   ` Duncan Sands
2005-04-28  0:54     ` Randy Brukardt
replies disabled

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