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.3 required=5.0 tests=BAYES_00,INVALID_MSGID, MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ab36006a122bb868 X-Google-Attributes: gid103376,public From: Ted Dennison Subject: Re: Overlay allowability Date: 2000/05/03 Message-ID: <8epqhg$hqa$1@nnrp1.deja.com>#1/1 X-Deja-AN: 618782857 References: <390D94FB.D23390D4@lmco.com> <8eketr$i3c$1@nnrp1.deja.com> <3910514D.13BF2DE1@Raytheon.com> X-Http-Proxy: 1.0 x36.deja.com:80 (Squid/1.1.22) for client 204.48.27.130 Organization: Deja.com - Before you buy. X-Article-Creation-Date: Wed May 03 18:18:36 2000 GMT X-MyDeja-Info: XMYDJUIDtedennison Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/4.7 [en] (WinNT; I) Date: 2000-05-03T00:00:00+00:00 List-Id: In article <3910514D.13BF2DE1@Raytheon.com>, "Samuel T. Harris" wrote: > Many times the need for such overlays is a continual need > throughout a section of code. Several calls to unchecked_conversion > is simply to slow and does present a consistency problem > associated with having two separate objects instead of two > overlayed objects. This consistency problem can be exploited > in a tasking environment and cause unpredictable results. Quite true. But what about unchecked-converting access types, like I was referring to? In that case, there is only *one* object, and that fact is quite clear to both the compiler and the reader. It certianly isn't significatnly slower to work this way. An optimizer might even be able to remove the extra dereferences, making the speed the same. You don't have to worry about initilization issues, as only the original object's initialzations get applied (just like one would expect). I think the tasking issue is a red herring. In a tasking environment, you have a consistency problem with *any* object (as each task may keep register copies of it). There ways to prevent or work around it in Ada of course. But I'd be very worried to add overlays into the mix. (eg: Does "pragma Atomic" work for both views of an overlaid object, or just the one?. Do synchronization points update my overlay's view of the object, if my task uses only the overlay and some other task uses only the original object? In fact, I'd be a bit worried about this whole thing in general. In Ada 83 doing this was defined as erronious. I figured that was because a chunk of code working on an object might temporarily save the object's value in a register, which would make the view from the other overlay invalid. If its safe to do that with the current version of Ada, how do Ada compilers ensure consistency between the overlaid views? -- T.E.D. http://www.telepath.com/~dennison/Ted/TED.html Sent via Deja.com http://www.deja.com/ Before you buy.