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, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,d23826ff0acb491b X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!news4.google.com!proxad.net!feeder1-2.proxad.net!194.25.134.126.MISMATCH!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Gem 39 - compiler specific? Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <9e0bbbcd-260f-48ed-8043-d6280c633e85@h3g2000yqa.googlegroups.com> <19268dbw82hf4.aii8as09aapk.dlg@40tude.net> <4bff103b-1797-4e2b-9dcf-7466b667c59b@d9g2000prh.googlegroups.com> <1s8kuin5t96vr$.1taw9mluqlplz$.dlg@40tude.net> <1bf4b63a-1e2d-41f1-97c6-8324d4b829ff@z3g2000prd.googlegroups.com> Date: Thu, 3 Sep 2009 22:26:59 +0200 Message-ID: <6o3frhrv0n0p$.8wj0gszs5h07$.dlg@40tude.net> NNTP-Posting-Date: 03 Sep 2009 22:26:59 CEST NNTP-Posting-Host: e0202a46.newsspool3.arcor-online.net X-Trace: DXC==RHXfU`S0ioUoRk[hk2WalMcF=Q^Z^V3h4Fo<]lROoRa^YC2XCjHcbiBX`cZ>N=R`hDNcfSJ;bb[eIRnRBaCd On Thu, 3 Sep 2009 10:27:57 -0700 (PDT), Adam Beneschan wrote: > On Sep 3, 9:38�am, "Dmitry A. Kazakov" > wrote: >> On Thu, 3 Sep 2009 08:26:50 -0700 (PDT), Adam Beneschan wrote: >>> On Sep 3, 12:26�am, "Dmitry A. Kazakov" >>> wrote: >>>> Skewed address is not a problem here. The problem is that >>>> System.Address_To_Access_Conversions should take an access type as a >>>> parameter rather than declare it new. This makes its use quite limited. >> >>> I don't see any limitation, at least where To_Pointer is concerned >>> (which is what the above code needed to use). �If you declare an >>> instance of this package for any object type T: >> >>> � type Convert_T_Access is new System.Address_To_Access_Conversions >>> (T); >> >>> then an object of type Convert_T_Access.Object_Pointer can be >>> converted to any access type whose designated type is T. �I checked >>> through the legality rules in 4.6, and I couldn't find a way to >>> declare an access-to-T type that you couldn't convert an >>> Object_Pointer to. �Thus, if you have any access type >> >>> � type Acc_T is access T; �[or access all T, or access constant T] >> >>> you can convert an address Addr to an Acc_T by saying: >> >>> � Acc_T (Convert_T_Access.To_Pointer (Addr)) >> >> But Acc_T is a pool-specific access, while Address_To_Access_Conversions >> creates a general access type. > > Sigh... I missed that---you can't convert a general access type to a > pool-specific one. 4.6 can be hard to follow, the way it's organized, > but that's not a good excuse. I've read it enough times that I should > know better. > > However, one could make that case that if you declare a pool-specific > access type, then by definition it should point to something that's in > a pool; and that if you want an access that could point to an > arbitrary address (as Access_To_Address_Conversions would let you do), > you should use a general access type. Address may have some specific representation when points into a pool. The idea of Access_To_Address_Conversions is to provide programmer a bit more safety than Unchecked_Conversion would. Why do we have Access_To_Address_Conversions? Why not to require Unchecked_Conversion to do all the checks Access_To_Address_Conversions does in the corresponding cases? I mean, there is no obvious reason why the implementation of Access_To_Address_Conversions should be safer than one of Unchecked_Conversion. The information the compiler has at the instantiation point is just same. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de