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.1 required=5.0 tests=BAYES_00, PP_MIME_FAKE_ASCII_TEXT autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,470860aa3e635a7 X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!news3.google.com!news4.google.com!feeder1-2.proxad.net!proxad.net!feeder1-1.proxad.net!club-internet.fr!feedme-small.clubint.net!nuzba.szn.dk!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: GNAT for MS Visual Studio Date: Sat, 6 Oct 2007 22:19:43 -0500 Organization: Jacob's private Usenet server Message-ID: References: <13duou81kg3sd1c@corp.supernews.com> <13f3e0vbb05s47c@corp.supernews.com> <13f6eg0te46m2a3@corp.supernews.com> <4xsl4zw3bp.fsf@hod.lan.m-e-leypold.de> <1191357491.860178.230380@22g2000hsm.googlegroups.com> <4702ADCC.7080209@obry.net> <1191439439.120567.172630@g4g2000hsf.googlegroups.com> <4703F02D.3030207@obry.net> <1191682021.844225.236870@g4g2000hsf.googlegroups.com> <4707A3D0.3070702@obry.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: jacob-sparre.dk 1191727011 9416 69.95.181.76 (7 Oct 2007 03:16:51 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Sun, 7 Oct 2007 03:16:51 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 Xref: g2news2.google.com comp.lang.ada:2333 Date: 2007-10-06T22:19:43-05:00 List-Id: "Pascal Obry" wrote in message news:4707A3D0.3070702@obry.net... > Matthew Heaney a �crit : > > No, this is incorrect. The container keeps track of nested calls > > (e.g. Query_Element, Iterate) using a count, in order to prevent > > container misuse (e.g. deleting the element while it's being > > queried). So even though the logical view of the container doesn't > > change, then physical view does change, and so the standard requires > > that multiple tasks accessing a container must be properly > > synchronized, even when the access is read-only. > > Outch! Big mistake to require this to me :( > > Maybe something like "Don't let best be enemy of good" ! > > That's probably the first time I'm very surprised and annoy by an Ada > design decision. It seems that there is good reasons... but frankly not > something really user friendly to me :( If you want dangerously unsafe containers, you are welcome to write them yourself. But they don't belong in the standard (surely not as the sole example of containers). For me, the most important advantage of the containers is that they can be made safe (in the absence of unsafe operations on an object containing a container). It's not necessary to have any operations that fail to detect dangling cursors and the like -- this is a big advantage over directly using access types to create a list or vector. But such implementations require housekeeping even for reading. Similarly, the case that Matt mentioned would make it trivial to have undetected errors that could cause serious trouble down the road. We were explicitly asked to minimize the cases of erroneous execution (that is, totally unpredictable result); it's quite possible that the containers would have been rejected altogether if we had not followed that recommendation. The implementations that I've been planning to use for the containers would require locking in order to provide any task safety -- meaning that I would have had to either give up on safety or performance -- not a good trade-off. The containers having different rules than those for *all* other Ada libraries (including things like matrix operations) would be weird, to say the least. Anyway, the point is that a lot of thought and debate went into this decision. We also started a project to create a set of protected containers for multitasking use (not much is happening with it, though, as its priority is lower than the ASIS update and fixing bugs in the standard). Randy.