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,9506bdc34331969a X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!postnews.google.com!j9g2000prh.googlegroups.com!not-for-mail From: Adam Beneschan Newsgroups: comp.lang.ada Subject: Re: put of access type Date: Thu, 20 Aug 2009 18:20:00 -0700 (PDT) Organization: http://groups.google.com Message-ID: <1585c4aa-6450-4b7f-8e63-05a3faa8b4b8@j9g2000prh.googlegroups.com> References: <8sho8596j3qnja38id9ipejk0opkcn5b5m@4ax.com> <4a8cea9c$1@news.post.ch> NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1250817600 29719 127.0.0.1 (21 Aug 2009 01:20:00 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Fri, 21 Aug 2009 01:20:00 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: j9g2000prh.googlegroups.com; posting-host=66.126.103.122; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; WOW64; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30618),gzip(gfe),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:6958 Date: 2009-08-20T18:20:00-07:00 List-Id: On Aug 20, 5:18=A0pm, "Randy Brukardt" wrote: > "Martin Krischik" wrote in message > > news:4a8cea9c$1@news.post.ch... > > > > > > > Randy Brukardt schrieb: > >> "Adam Beneschan" wrote in message > >>news:c9aec6d6-4e9b-4bf6-9586-68a237175c9d@i18g2000pro.googlegroups.com.= .. > >> ... > >>> Also, there's no rule saying that an access value has to be an addres= s > >>> at all. =A0It's certainly conceivable that an access value may be > >>> implemented as a reference to some storage pool and an offset into > >>> that pool, allowing for the possibility that the memory management > >>> system may just decide to pick up the whole pool and move it to some > >>> other address, without making any of the access values invalid. > > >> I think the Ada 95 definition of storage pools would make this > >> implementation hard to make work. (Which is unfortunate, it would have > >> worked fine in Ada 83). > > > It still works: > > I think you missed my point. The definition of the Allocate function for = a > storage pool returns an System.Address. Moreover, there is no notificatio= n > when the access value returned from Allocate is dereferenced or converted= to > another access type. So if Allocate returns an offset rather than an > address, the compiler generated code to implement .all and to implement > conversions to anonymous access type is not going to take that into > account -- it will think it received a System.Address. So this cannot wor= k > for any user-defined storage pool. It could still work using a type like Martin suggested---as long as the compiler sets up an access type with Pool_Access=3DFalse whenever it is using a user-defined storage pool. It would use Pool_Access=3DTrue only for the default storage pool. Yes, that makes it less useful. More generally, though: My comment assumed that there would be a lot of compiler support required for an access type that is implemented as a pool reference plus an offset. There's no reason that a compiler that has this support couldn't also add its own rule that it supports this kind of access type only for storage pools that are descendants of System.Storage_Pools.Movable_Storage_Pools.- Root_Movable_Storage_Pool (with this last child package and type being vendor-defined). This type would contain additional operations that the compiler would depend on to get things right; Allocate would still return a System.Address, but some new operation defined for Root_Movable_Storage_Pool would convert that address to an offset, and the compiler would depend on that operation when setting up an access type with Pool_Access=3DTrue. A lot of work, certainly, and probably not worth the effort unless some customer has special requirements. But my original point wasn't intended to suggest anything practical, but just to get people thinking a bit about the *possibility* that an access type doesn't need to be implemented as an address, and thus to start thinking about things like that in more abstract ways instead of being tied to low- level concepts that other languages sometimes make you think in. -- Adam