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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,55f6e230b02eff2f X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news4.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: "Alex R. Mosteo" Newsgroups: comp.lang.ada Subject: Re: Containers - nontrivial element access Date: Tue, 02 Oct 2007 01:52:57 +0200 Message-ID: <5mdfipFcv1dsU1@mid.individual.net> References: <1191275759.184463.238350@n39g2000hsh.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Trace: individual.net FaMpwdtk2GIEw6yW+yVzgAbEteJuXTcu/+1ApaCs8Bh2hgxhA= Cancel-Lock: sha1:5klGFBTNpmaB0sy6u8XCq3o5WZM= User-Agent: KNode/0.10.5 Xref: g2news2.google.com comp.lang.ada:2241 Date: 2007-10-02T01:52:57+02:00 List-Id: Maciej Sobczak wrote: > I was thinking recently about what is wrong with the containers > interface. ;-) > > Consider the following problem: > There is a record type (for example Person) with a couple of fields > (for example Salary) that together make the whole a bit heavy, so that > unnecessary copying of the whole is to be avoided. Objects of this > type are stored in the container. > > I would like to swap salaries of two guys which I can refer with the > index/iterator/cursor/etc. The reference method is not really > important - what is important is the problem of modifying more than > one element in the container. > > C++ example is easy: > > vector people; > // ... > swap(people[x].salary, people[y].salary); > > I hope it is obvious what it does (suppose x and y are some indices > into the vector). Just in case it isn't - all the components of the > two records stay intact except the salary, which is swapped between > the two. C++ makes it possible by explicitly returning a reference > from the method that accesses the element. > > What would you suggest as the Ada solution for this problem? > > The Update_Element procedure with its access to the user-provided > modifying procedure requires to pass data "under the table" (like with > a separate variable declared aside the modifying procedure) - and > seems to be just clunky. Is this the only possibility? I don't think that's reproducible as-is with the standard containers. It must be more verbose. There's no way to get a reference to the element in the Ada containers (unless you want to go the 'Unrestricted_Access way inside Update_Element, but that would require anyway extending the standard containers), so you can have dangling cursors but no dangling pointers. I'm not sure the solution is clunky, unless you consider verbose=clunky. Local scope subprograms seems just the kind of feature to do this. Then again, it may get *very* verbose specially when comparing to your one-liner. And subsets like SPARK may forbid it altogether, although dynamically allocating containers may be out of the picture when using SPARK anyway. There are additional differences, if I'm not mistaken (my C++ is a bit outdated). [] is, I think, unchecked (unlike .at()), so you could get a violation with that code that shouldn't be possible in Ada. There was a recent thread (started by myself) on the amount of copying involved in the use of the containers. Someone said that returning accesses was deemed too unsafe and thus dropped, IIRC. I have not a strong position on if dangling cursors is a great improvement over dangling accesses, given what we gain/lose; in my experience a dangling cursor has been always as bad as a dangling pointer, in the sense that the program was erroneous beyond recovery; admittedly I have never got a memory violation using the containers so post-hoc diagnostics are quicker. Leaving scope issues aside (I'm too tired now to think about the differences between the C++ and Ada designs), references in C++ is one of my loved/hated features. I'm obsessed with them, they're really powerful and give you a great deal of control (but also over things I'd prefer not to have to worry about). On the other side, I see people getting confused with them so easily, specially people coming from other non-CS disciplines, that I'm somehow glad not to have to deal with them in Ada in a cooperative context. > > -- > Maciej Sobczak * www.msobczak.com * www.inspirel.com