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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,a00006d3c4735d70 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-01-10 18:38:25 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!newsfeed.icl.net!newsfeed.fjserv.net!logbridge.uoregon.edu!arclight.uoregon.edu!wn11feed!worldnet.att.net!199.45.49.37!cyclone1.gnilink.net!spamkiller2.gnilink.net!nwrdny01.gnilink.net.POSTED!0e8a908a!not-for-mail From: Hyman Rosen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Certified C compilers for safety-critical embedded systems References: <1731094.1f7Irsyk1h@linux1.krischik.com> <3ff1b8ef.614528516@News.CIS.DFN.DE> <3FF1E06D.A351CCB4@yahoo.com> <3ff20cc8.635997032@News.CIS.DFN.DE> <3ff9df16.30249104@News.CIS.DFN.DE> <1665674.ZrTUW4qaQq@linux1.krischik.com> <1073409810.463948@master.nyc.kbcfp.com> <1073421950.964139@master.nyc.kbcfp.com> <3ffd9d14.1526346@News.CIS.DFN.DE> <1073659951.261166@master.nyc.kbcfp.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Date: Sun, 11 Jan 2004 02:38:23 GMT NNTP-Posting-Host: 162.84.196.162 X-Complaints-To: abuse@verizon.net X-Trace: nwrdny01.gnilink.net 1073788703 162.84.196.162 (Sat, 10 Jan 2004 21:38:23 EST) NNTP-Posting-Date: Sat, 10 Jan 2004 21:38:23 EST Xref: archiver1.google.com comp.lang.ada:4319 Date: 2004-01-11T02:38:23+00:00 List-Id: Dmitry A. Kazakov wrote: > Strange, I would expect you telling us [rightfully] that in this particular > case C++ is better than Ada. C++ has abstract arrays (operator[]), Ada does > not. Ada's handling of native arrays is so superior to C++'s that I wouldn't presume to brag about C++'s operator[]. Anyway, given that C++ can overload function call, and that can take an arbitrary number of parameters, having operator[] isn't all that exciting. Furthermore, C++ has no real way of inferring from context to what use a dereference will be put, and that complicates matters very much. For example, C++'s std::string has an operator[] which can be used for reading or for modification std::string s("Help!"); char p = s[3]; // p s[3] = "l"; // Hell! The s[3] construct is not supplied with an information as to whether it is needed for reading or for writing. As a result, string implementations must assume that every call to operator[] will result in potentially changing the string, so if they share duplicate strings behind the scenes, merely calling operator[] forces the sharing to be broken. You can play tricks with proxy classes and such, but it all just bogs down.