From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 23 Aug 93 14:11:03 GMT From: alex@MIMSY.CS.UMD.EDU (Alex Blakemore) Subject: Re: Data Overlays Message-ID: <70605@mimsy.umd.edu> List-Id: In article <1993Aug19.185126.27655@iplmail.orl.mmc.com> rgilbert@orl.mmc.com wr ites: > Method 3 : Use Unchecked_Conversion to pass (by reference) a parameter to a procedure > procedure Overlay(Y : in out TYPE_2) is > function To_Type_2 is new Unchecked_Conversion(TYPE_1, TYPE_2 ); > Overlay(To_Type_2(X)); -- Now reference to object as other type > The advantages are: .... The disadvantages are ... it doesnt compile, its not legal Ada you cant use a function result as an actual parameter of mode in out. ut I believe it should work. no comment :-) in my opinion, its ok to use an overlay if it works to solve your problem and there is no other way without copying a large buffer. just isolate it, document it, and dont expect it to port. the one case where I found it necessary was trying to read into a large string buffer using Posix IO (which defines its own string type) the only portable solution was to read into a posix string, and then use the posix conversion function to convert between the two (really identical) string types. so in that case, there were only two choices a. copy each IO buffer an additional time just to change its type, (but not its representation) + portable - wasteful b. use an overlay to allow reading with posix string type and access with Ada s tring type + efficient - perhaps not portable since the buffers were large, and IO performance was a major concern and changi ng the posix interface (or the rest of the application) were out of the question, I think using an overlay was the right choice. of course, it would be a lot easier if the posix interface used standard.string , but I suppose there are still a few EBCDIC machines somewhere -- Alex Blakemore alex@cs.umd.edu NeXT mail accepted -------------------------------------------------------------- "Without an engaged and motivated human being at the keyboard, the computer is just another dumb box." William Raspberry