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=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,f2690a5e963b61b6 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!newshub.sdsu.edu!elnk-nf2-pas!newsfeed.earthlink.net!stamper.news.pas.earthlink.net!stamper.news.atl.earthlink.net!newsread1.news.atl.earthlink.net.POSTED!14bb18d8!not-for-mail Sender: mheaney@MHEANEYX200 Newsgroups: comp.lang.ada Subject: Re: GCC 4.0 Ada.Containers Cursor danger. References: <1120474891.635131.216700@g44g2000cwa.googlegroups.com> <1121573057.159416.274980@g49g2000cwa.googlegroups.com> <42da2eb5$0$20137$9b4e6d93@newsread2.arcor-online.net> From: Matthew Heaney Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 17 Jul 2005 14:26:41 GMT NNTP-Posting-Host: 24.149.57.125 X-Complaints-To: abuse@earthlink.net X-Trace: newsread1.news.atl.earthlink.net 1121610401 24.149.57.125 (Sun, 17 Jul 2005 07:26:41 PDT) NNTP-Posting-Date: Sun, 17 Jul 2005 07:26:41 PDT Organization: EarthLink Inc. -- http://www.EarthLink.net Xref: g2news1.google.com comp.lang.ada:3647 Date: 2005-07-17T14:26:41+00:00 List-Id: Georg Bauhaus writes: > Dmitriy Anisimkov wrote: > > M.Delete (C2); > > pragma Assert (not Has_Element (C2)); > > pragma Assert (not M.Contains ("two")); > > -- double hash overhead. > > Replace_Element (C, -2); -- dangling cursor > > I thought the Replace_Element line was the source of an > undetected dangling cursor in your initial example. Yes, that's my understanding too. > Supposedly the new checking is inside Replace_Element, which now fails > with "bad cursor in Replace_Element". Some of that checking was already in place for the hashed map. Did the OP compile with assertions enabled? What I find baffling is that the OP complained that the cursors were dangerous, since the library failed to detect a dangling cursor reference. But when the dangling reference *is* detected, the OP complains that the library still isn't good enough, either because cursors have "too much overhead," or aren't "safe enough." (If the library can detect dangling cursors, then what other safety issues are there?) His main complaint seems to be that cursors exist at all. Yes, cursors are tied to the iteration mechanism (a compromise of sorts, since the language itself doesn't have support for "real" iterators), but cursors have uses beyond mere iteration. > The two asserts above look like "informative" assertions > to me, expressing what Delete has done. Yes, exactly. > They are not in the library, they are in a client program, and > therefore don't add overhead to library subprograms at all. They also > don't check C. Note that if I had checked cursor C (by calling Has_Element, say), then that would have just raised the assertion error sooner.