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,703c4f68db81387d X-Google-Thread: 109fba,703c4f68db81387d X-Google-Thread: 115aec,703c4f68db81387d X-Google-Thread: f43e6,703c4f68db81387d X-Google-Attributes: gid103376,gid109fba,gid115aec,gidf43e6,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!news.glorb.com!newscon02.news.prodigy.com!newscon06.news.prodigy.com!prodigy.net!newsfeed-00.mathworks.com!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada,comp.lang.c++,comp.realtime,comp.software-eng Subject: Re: Teaching new tricks to an old dog (C++ -->Ada) Date: 10 Mar 2005 18:04:06 -0500 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <4229bad9$0$1019$afc38c87@news.optusnet.com.au> <1110032222.447846.167060@g14g2000cwa.googlegroups.com> <871xau9nlh.fsf@insalien.org> <3SjWd.103128$Vf.3969241@news000.worldonline.dk> <87r7iu85lf.fsf@insalien.org> <1110052142.832650@athnrd02> <1110284070.410136.205090@o13g2000cwo.googlegroups.com> <395uqaF5rhu2mU1@individual.net> <112rs0bdr2aftdf@corp.supernews.com> NNTP-Posting-Host: shell01-e.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls4.std.com 1110495847 14276 69.38.147.31 (10 Mar 2005 23:04:07 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Thu, 10 Mar 2005 23:04:07 +0000 (UTC) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: g2news1.google.com comp.lang.ada:9072 comp.lang.c++:45018 comp.realtime:1222 comp.software-eng:4790 Date: 2005-03-10T18:04:06-05:00 List-Id: CTips writes: > - Usually the checks will be added every place they are needed, and then > the usual optimizations will be used to eliminate them. In other words, > if one adds the checks manually, the compiler should eliminate them > identically. That's true in cases where the manual checks are equivalent to the built-in checks. But there are important cases where they're not. For example, if you pass an integer as a parameter, and inside the called procedure use that as an array index, it is typically natural to declare the integer parameter as a subrange whose bounds match the array bounds (even if those bounds are dynamic). So the array-indexing check can be optimized away. C++ has no integer subranges, so if you did the equivalent in C++, with a manual check, the compiler could not normally optimize it away. OTOH, I suppose you could program integer subranges in C++ using templates. You are correct that Ada's run-time checks are not entirely free in all cases. In order to check the bounds, the bounds must be stored in memory, which is a cost. And even if the checks are suppressed, I don't know of any Ada compiler that will avoid storing the bounds. This is partly because in Ada you can query those bounds (Some_Array'Length, for example). On the other hand, if you're querying the bounds, the equivalent in C++ would have to store the bounds, too. > How easy is it to build an arena allocator in Ada? Pretty straightforward. You write a package containing a "storage pool type", with operations like Allocate (which returns an Address). You then attach your storage pool to particular pointer types, and then the generated code will call your operations instead of the compiler-provided ones. Inside your storage pool code, you will no doubt have to do all kinds of low-level stuff -- address arithmetic, perhaps. Ada has plenty of support for that level of coding. > Given a processor with load-word-locked and store-word-conditional, how > would I build an atomic increment function? Use a machine-code insert. Same way you'd do it in any language, I suppose. And wrap it in an abstraction layer so you can have some hope of porting to a machine without those instructions. - Bob