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: a07f3367d7,aba1514f4a1fc450,start X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,UTF8 Received: by 10.66.80.166 with SMTP id s6mr1907818pax.30.1345989949375; Sun, 26 Aug 2012 07:05:49 -0700 (PDT) Path: a8ni56442646pbd.1!nntp.google.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!goblin1!goblin.stu.neva.ru!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail From: Brian Drummond Newsgroups: comp.arch,comp.lang.ada Subject: Re: Have the Itanium critics all been proven wrong? Date: Wed, 22 Aug 2012 12:39:49 +0000 (UTC) Organization: A noiseless patient Spider 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> Mime-Version: 1.0 Injection-Date: Wed, 22 Aug 2012 12:39:49 +0000 (UTC) Injection-Info: mx04.eternal-september.org; posting-host="0e44dd4a3c4e0a6e83a86f947fb780ae"; logging-data="29882"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX187VXbEQ9oSNUSrm4leJ7Z24mcfHOYnmJE=" User-Agent: Pan/0.135 (Tomorrow I'll Wake Up and Scald Myself with Tea; GIT 30dc37b master) Cancel-Lock: sha1:HMMgIYCigR5sfz5W0ULnUNqoZVI= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Date: 2012-08-22T12:39:49+00:00 List-Id: On Wed, 22 Aug 2012 03:32:00 -0700, Michael S wrote: > On Aug 22, 12:09 am, 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 much > info as they like in the intermediate files and do as much processing as > needed in the link phase. > Times change, noways C and in particular C++ developers very rarely rely > on language-agnostic linkers, but language features that would make that > 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. > BTW, how Ada deals with that? That it how pointer (access) to auto > object distinguished from pointers to dynamic 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. >> Ada ... doesn't by default supply a garbage collector. > Automatic garbage collection not aided by compiler is certainly possible > 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. 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