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 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,UTF8 Received: by 10.66.74.40 with SMTP id q8mr1653828pav.19.1345990176320; Sun, 26 Aug 2012 07:09:36 -0700 (PDT) Path: a8ni56502815pbd.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!solaris.cc.vt.edu!news.vt.edu!news.glorb.com!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 15:06:34 +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 15:06:34 +0000 (UTC) Injection-Info: mx04.eternal-september.org; posting-host="0e44dd4a3c4e0a6e83a86f947fb780ae"; logging-data="4690"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18U21myIYFJubEwgkCNrCla0BPVn1CS1IA=" User-Agent: Pan/0.135 (Tomorrow I'll Wake Up and Scald Myself with Tea; GIT 30dc37b master) Cancel-Lock: sha1:bQcFBO1IwZqAr1ownPuyNenUmJc= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Date: 2012-08-22T15:06:34+00:00 List-Id: On Wed, 22 Aug 2012 07:00:31 -0700, Michael S wrote: > On Aug 22, 3:39 pm, Brian Drummond wrote: >> On Wed, 22 Aug 2012 03:32:00 -0700, Michael S wrote: [... discussion of private types exported to module A from B] >> 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. If a module has exported a pointer to an "auto object" then the accessibility checks have been circumvented by unchecked_access or unchecked_conversion. In which case ... yes, caveat programmer! Pointers passed from a module will generally be to static or dynamic objects. Which, if dynamic, can be freed by unchecked_deallocation. Again : caveat programmer. One benefit of the private type, forcing all accesses to an object being through its own methods, is that B can be implemented as a "controlled type", which allows B's programmer to make such mistakes less common. For example, B's object may be reference counted, and only freed after all its handles are released. (And yet a pathological A may cheat, and access it after release.) Controlled types could probably be used as the basis for a garbage collector. >> > But is not such GC >> > significantly less efficient than GC aided by compiler? >> 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; ... > 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. True. If the GC implementor has foreseen the pattern you need or something close enough, then compiler-provided GC would probably be more efficient. - Brian