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.3 required=5.0 tests=BAYES_00,FORGED_YAHOO_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,aba1514f4a1fc450 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII Received: by 10.68.232.1 with SMTP id tk1mr1471788pbc.7.1345990070620; Sun, 26 Aug 2012 07:07:50 -0700 (PDT) Path: t10ni65006911pbh.0!nntp.google.com!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!news.snarked.org!newsfeed.news.ucla.edu!ihnp4.UCSD.Edu!nntp.ucr.edu!usenet.stanford.edu!postnews.google.com!q22g2000vbx.googlegroups.com!not-for-mail From: Michael S Newsgroups: comp.arch,comp.lang.ada Subject: Re: Have the Itanium critics all been proven wrong? Date: Wed, 22 Aug 2012 07:00:31 -0700 (PDT) Organization: http://groups.google.com Message-ID: References: <5021874F.1747D0BF@sonic.net> <1e1tf9-0kp2.ln1@ntp6.tmsw.no> <46f19bfc-930e-4f06-b5a6-c60f39cfda0c@p14g2000yqk.googlegroups.com> <077b12f6-1196-4b5c-bbdb-04291b1ae616@q22g2000vbx.googlegroups.com> <589825d2-d998-456a-9c37-c8ae13e1e7bc@e29g2000vbm.googlegroups.com> NNTP-Posting-Host: 62.219.244.2 Mime-Version: 1.0 X-Trace: posting.google.com 1345644032 32521 127.0.0.1 (22 Aug 2012 14:00:32 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 22 Aug 2012 14:00:32 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: q22g2000vbx.googlegroups.com; posting-host=62.219.244.2; posting-account=yxhsVAkAAAAd1ExczpaZ2Ptm4WnXJOwS User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20100101 Firefox/11.0,gzip(gfe) X-Received-Bytes: 6423 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2012-08-22T07:00:31-07:00 List-Id: On Aug 22, 3:39=A0pm, Brian Drummond wrote: > On Wed, 22 Aug 2012 03:32:00 -0700, Michael S wrote: > > On Aug 22, 12:09=A0am, Brian Drummond wrote: > > >> Heh, the book I learned C++ from didn't even mention STL, (or > >> namespaces for that matter) and regarded templates as a bit unstable. > >> When did STL appear? (And yes, I have newer books now...) > > > Interview with Alex Stepanov. > >http://www.sgi.com/tech/stl/drdobbs-interview.html > > So, not long after Ada-95. > Interesting article - he even speculates that STL could be implemented in > Ada. I suppose Ada.Containers goes some way towards that. > > >> > Obsession with separate compilation does not help either. > > >> Does not help what? I'm unclear what point you have in mind? > > Ada has his own library/link system. They can store as little or as muc= h > > info as they like in the intermediate files and do as much processing a= s > > needed in the link phase. > > Times change, noways C and in particular C++ developers very rarely rel= y > > on language-agnostic linkers, but language features that would make tha= t > > type of analysis possible still absent. > > Indeed - in gcc, Ada and C use the same linker! though Ada passes through > a binding stage handling additional inter-module information. C and C++, > as far as I can see, still rely on external tools to (mis?)manage the > dependencies. Well, we are not at managing dependencies now, don't we? We are at error/warning detection and reporting during link phase. Gnu ld of today is very far of language agnostic. In Microsoft world people routinely use link-time code generation. So, original technical reasons for not doing that sort of checks do not exist any more. But the checks are still not provided due to deficiencies of the language itself. > > > BTW, how Ada deals with that? That it how pointer (access) to auto > > object distinguished from pointers to =A0dynamic or static objects when > > they (pointers) are passed to the different module? > > Now you have caught me; it's a good question but I can't answer it > accurately. So I have added c.l.a to the newsgroups in the hope that > others will keep me straight. > > I believe pointers to "auto" (C-speak for stack-allocated?) objects can > only be passed down the call stack; accessibility checks would otherwise > fail (unless defeated by unchecked_access). > > Given modules A and B, it's not normal to actually access B's pointers > from module A. More commonly A would only see a "private type" exported > from B, and not even know it was a pointer. A can hold such types, but > can only use them by invoking methods from B (such as accessors) on them. > This puts B in charge of the object lifetimes; if A wants to access a > stale object, expect an exception. Exception, if I am lucky. If I am less lucky, the physical place of old auto object is now occupied by new auto object of the same or compatible type and the call to accessor caused silent corruption. > > >> Ada ... doesn't by default supply a garbage collector. > > Automatic garbage collection not aided by compiler is certainly possibl= e > > and done in practice (Boehm ?). But is not such GC significantly less > > efficient than GC aided by compiler? > > such as Java's GC for example? > > I don't know that would generally be the case. If you need GC, you may > often be able to structure the application to gain some advantage from > its properties; for example, it may make identical sized garbage objects, > or it may have natural "down times" when you can harmlessly schedule > (part of) a GC. That's not a good argument. Compiler-supplied GC can also provide hint interface, like Compact_righ_now, Please_do_not_compact_if_you_dont_have_to. > > Without knowing those properties, you can't design a GC to optimally fit. > So I believe that compiler-supplied GC would often be less efficient. In > that respect, I agree with the decision shared by Ada and C++, to not > provide it by default. > > - Brian But when compiler is aware of GC the tracking of liveness of objects become much easier (for some implementations - trivial). You can organize your memory database in such way that you will never have to scan things.