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=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!newsfeed.fsmpi.rwth-aachen.de!newsfeed.straub-nv.de!reality.xs3.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: A few questions Date: Wed, 18 Nov 2015 16:27:31 -0600 Organization: JSA Research & Innovation Message-ID: References: <5007b311-5d2e-448c-b8c8-fc2e2d88ea5e@googlegroups.com> <8hw612c7lfik.1cy0uanjjnpzv$.dlg@40tude.net> NNTP-Posting-Host: rrsoftware.com X-Trace: loke.gir.dk 1447885652 9618 24.196.82.226 (18 Nov 2015 22:27:32 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Wed, 18 Nov 2015 22:27:32 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:28445 Date: 2015-11-18T16:27:31-06:00 List-Id: "Dmitry A. Kazakov" wrote in message news:ojkj222dh308.y5p6iz7kqgjc.dlg@40tude.net... > On Tue, 17 Nov 2015 15:30:28 -0600, Randy Brukardt wrote: > >> "Dmitry A. Kazakov" wrote in message >> news:8hw612c7lfik.1cy0uanjjnpzv$.dlg@40tude.net... >>> On Mon, 16 Nov 2015 13:13:05 -0600, Randy Brukardt wrote: >>> >>>> You're speaking nonsense. The element is part of the container, and the >>>> only way to access it is from the container. >>> >>> I think you are confusing indices with iterators. The very concept of >>> the >>> iterator is accessing elements without the container as opposed to the >>> index. >> >> That's surely not my idea of an iterator. And it doesn't work for Ada in >> any >> case, as that would allow altering elements of constant containers (we >> prevent that in the containers library by requiring an "in out" container >> parameter in all cases where modifications are allowed). > > Access /= Update. Compare it with "access constant T" True, but irrelevant. Iterators without update compatibilities are way to limiting to be of any value. > The difference between index and iterator is that accessing through the > index requires the container. An index is always relative to some > container. The iterator does not need the container, the container is > implicit. This is the confusion between "iterators" and "cursors" that the C++ libraries have. What you are describing as an "iterator" is exactly the definition of a cursor in Ada. To me, iterators are active objects, not just indexes. >>> Both concepts of >>> iterator and index have fundamental operations to create a new instance >>> referencing some other element (next, previous, sibling, parent, >>> neighbour >>> etc) >> >> The C++ containers mix up the ideas of iterators and cursors (they're >> essentially the same thing there). By your description, you want them to >> be >> the same -- but in that case, just use the cursors and be done with it. >> You >> will sacrifice safety and ease-of-use to do so, but whatever. > > That is not my point. It is that Index + 1 is another index and that > Iterator.Next is another iterator. From the interface point of view you > don't need the container to get another instance of either. Next(Cursor) gets you another Cursor. (You can't use the prefix notation because Cursors aren't tagged, and that's because we can't have primitive operations of two tagged types, else they would have been tagged. But otherwise this is identical.) You don't need the container to call Next. But you do need the container to update the element. > And regarding safety, it is very important that you don't need the > container when accessing elements or advancing the iterator. Well-designed > iterators meant to keep the iteration state *inside* the iterator object > rather than in the container, for evident reasons. ??? If the container (not counting the contents of the elements) is modified while the iterator is executing, it doesn't matter where the iteration is happening -- you're not going to be able to maintain the invariants of the execution. That happens with explicit iteration in the Ada.Containers (that is, directly using Next and Cursors) -- where the effect is for the user to figure out (and it's often erroneous) -- and that happens with any possible iterator mechanism (using call-backs, or interfaces, or whatever) -- where Ada uses a tampering check to avoid problems (the container does not allow element insertions or deletions while an iteration is running). If you think allowing erroneous execution is somehow safe, you're in the wrong language forum. Randy.