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.7 required=5.0 tests=BAYES_00,INVALID_DATE, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,5850c59062ca527a X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1994-11-03 02:49:24 PST Path: bga.com!news.sprintlink.net!howland.reston.ans.net!math.ohio-state.edu!magnus.acs.ohio-state.edu!csn!boulder!news.coop.net!news.den.mmc.com!iplmail.orl.mmc.com!alcyone!rgilbert From: rgilbert@orl.mmc.com (Bob Gilbert) Newsgroups: comp.lang.ada Subject: Re: Type System.ADDRESS Date: 2 Nov 1994 15:45:46 GMT Organization: Martin Marietta Orlando Distribution: world Message-ID: <398c7a$f2a@theopolis.orl.mmc.com> References: Reply-To: rgilbert@orl.mmc.com NNTP-Posting-Host: alcyone.orl.mmc.com Date: 1994-11-02T15:45:46+00:00 List-Id: In article 7M7@inmet.camb.inmet.com, stt@spock.camb.inmet.com (Tucker Taft) writes: ->In article <395ecb$bjq@theopolis.orl.mmc.com>, ->Bob Gilbert wrote: -> ->>In article IEr@inmet.camb.inmet.com, ->>stt@dsd.camb.inmet.com (Tucker Taft) writes: -> ->>->What do you mean by "static" when referring to System.Address? ->>->-Tucker Taft ->> ->>I wish I knew exactly what I mean by static, but from the vendor ->>in question they state: ->> ->> Any assignments to type System.Address require a static expression. ->> ->>Apparently this limitation is what mucks up my generics. -> ->I suspect the limitation has to do with "address clauses," ->rather than "assignments." I am not surprised that a vendor ->requires the address in an address clause to be a link-time ->constant. If they do shared generics, that probably means ->you can have an address clause inside a generic. You're correct about the limitation having to do the address clauses. But the compiler in question here apparently requires the address clause to be a compile-time constant. I've used address clauses in generics with other Ada compiler's with no problems. For some reason this compiler puts this limitation on the use of address clauses (they claim it is due to their method of implementing System.Address ?). ->Address clauses are relatively nonportable in general, ->though we hope to see some improvement with Ada 9X. -> ->In the meantime, a somewhat (;-) more portable solution is ->to use access values, defined by an unchecked conversion from ->System.Address. So long as the designated subtype is ->not an unconstrained array subtype, most compilers ->have no problem converting Addresses to access values. ->(Rational compilers used to be an exception -- I don't know whether ->Apex is any different in this regard.) This is the method I have turned to. My problem is that I prefer to exploit the features designed into the language to accomplish their intended purpose. Address clauses are there for mapping data to memory and interrupts to tasks, and it bugs me a little to not be able to do this (at least with generics). Resorting to using access types and unchecked conversion to work around the problem seems to be contrary to their intended purpose. I hope I don't seem overly up- tight over this issue, but things like this do tend to errode the rational for using the language (readability, portability, etc.), and being an Ada supporter I'd like to see these sort issues confronted and solved (I'm just not sure if the problem is with the compiler vendor, the language specification, me, or some combination of the above). ->Note that Ada 9X has a package designed explicitly for ->this conversion (System.Storage_Elements.Address_To_Access_Conversions). Looking forward to it :-). -> ->>-Bob -> ->-Tucker Taft stt@inmet.com ->Intermetrics, Inc. ->Cambridge, MA 02138 BTW - Just what are "shared generics"? -Bob