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=-0.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,d02eb5c33ac65d9 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-03-10 03:57:18 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!snoopy.risq.qc.ca!newsfeed.news2me.com!newsfeed2.earthlink.net!newsfeed.earthlink.net!stamper.news.pas.earthlink.net!stamper.news.atl.earthlink.net!harp.news.atl.earthlink.net!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: Array and memory usage Date: Mon, 10 Mar 2003 06:57:06 -0500 Organization: MindSpring Enterprises Message-ID: References: <2397C8D4BA396B7A.ADB0E590CE8E5EAE.1C7AEC9AFCA7BE12@lp.airnews.net> NNTP-Posting-Host: d1.56.b4.48 X-Server-Date: 10 Mar 2003 11:57:17 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Xref: archiver1.google.com comp.lang.ada:35118 Date: 2003-03-10T11:57:17+00:00 List-Id: They're all "Quality Of Implementation" issues :-) Here's the thing: In Ada, it is *theoretically* possible for compilers to do a wonderful job with all sorts of things. However, when one starts examining the output of the available compilers in given circumstances and discovers that the output is *universally bad* in some respect, what difference does it make that the compiler writers might actually be able to do better? The fact is they didn't do better and unless you have truckloads of money to give them and months/years to wait for the end result, you're not going to get the output you want. In fairness to the compiler writers, they often start from some general solution that works (albeit inefficiently) for all cases, then they start looking at optimizations. In the case of a record type with default initial values, one can see that the initialization could be problematic in different contexts. If you declare the record globally, you'd like for that global memory to be statically initialized and your load image just has the bits set the way you want them. But what about when the record is allocated on the stack? Or if it comes from the heap? Or if one of the initializations is a function call? So they write an initializer that works for all the cases and the global memory variant suffers. There are probably lots of similar examples. In scenarios like that, you've got to work with fooling the compiler into doing what you want or working with various other techniques of getting the job done. (One can always resort to C and get the desired output. :-) So I guess the gripe is that while Ada may allow for efficient implementation it often doesn't get there because its just too hard to do it all. Sometimes you have to avoid the spiffy features because they aren't implemented well. Mostly, this is a realtime/embedded complaint that I have not had problems with in building workstation apps. Oddly, Ada works better in an adopted domain than it does in the domain it was intended for sometimes. :-) MDC -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/ Send Replies To: m c o n d i c @ a c m . o r g "Going cold turkey isn't as delicious as it sounds." -- H. Simpson ====================================================================== Mark Biggar wrote in message news:x6Saa.25310$eG2.4454@sccrnsc03... > > > > If you care about code size and efficiency, you can find a number of > > "surprises" and "gotchas" with Ada. > > Shouldn't the preelaborate pragma help with this problem? Otherwise > this is obviously a "quality or implementation" issue. >