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-7-bit Path: g2news1.google.com!news1.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!bloom-beacon.mit.edu!newsswitch.lcs.mit.edu!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: put of access type Date: Fri, 21 Aug 2009 10:47:21 -0400 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <8sho8596j3qnja38id9ipejk0opkcn5b5m@4ax.com> <4a8cea9c$1@news.post.ch> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls6.std.com 1250866041 13294 192.74.137.71 (21 Aug 2009 14:47:21 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Fri, 21 Aug 2009 14:47:21 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:vtyVCZAcSaCAovAXzINmWFQ2iyQ= Xref: g2news1.google.com comp.lang.ada:6974 Date: 2009-08-21T10:47:21-04:00 List-Id: "Randy Brukardt" writes: > "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 address >>>> at all. It'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. I still don't understand your point. I agree with your comments about Ada 95 user-defined Storage_Pools. But that feature did not exist in Ada 83, so you can't be referring to them when you say "worked fine in Ada 83". What worked fine in Ada 83 is to represent access values as offsets from some known place (e.g. segment-relative offsets on a 8086). I think that still works fine in Ada 95/2005 for pool-specific access types (which is the only kind that existed in Ada 83). The only relevant language change is that you can convert from pool-specific to general. So you have to be able to take your offset, and produce a "full" address, or whatever a general access type is represented as. As far as I can see, the addition of user-defined storage pools to the language is irrelevant here. (By the way, "pool-specific" is a misnomer. I was confused when I invented that term during Ada 9X!) I agree with you that it would be nice if user-defined storage pools _could_ be used with offsets, or other oddball representations of access types. >...The definition of the Allocate function for a > storage pool returns an System.Address. Moreover, there is no notification > 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 work > for any user-defined storage pool. > > A compiler *could* implement something like this for the default storage > pool. But that is exactly the case when you need a general implementation, > so it seems rather pointless. But you can't do this with a user-defined > storage pool. (I suppose a compiler could provide its own magic storage pool > with these semantics, but it is unlikely to be worth the effort.) - Bob