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: 6 Oct 92 15:58:18 GMT From: eachus@mitre-bedford.arpa (Robert I. Eachus) Subject: Re: Problem with inefficiency and records with variant parts Message-ID: List-Id: In article sidou@litsun.epfl.ch (Dominique Sidou) writes: We have a big problem with records variant an efficiency... we now need to do the following... v.s := 2; fill(v.c2); with: procedure fill (c : in out BigStruct2); We want to avoid casting v in the following way before the call to fill: declare bigstruct2var : BigStruct2; begin v := (2, bigstruct2var); -- very inefficient and useless in our case fill(v.c2); end; Any Comments, Ideas...??? The problem is one of different levels of abstraction. Procedure fill expects objects of type BigStruct2, and you want to operate on on objects of type t. Two possible solution approaches: First approach is to wrap fill to return a value of type t: function Fill return T is Temp: t(2); begin fill(Temp.c2) return Temp; end Fill; ... v := Fill; (You could make it a procedure if you like, in that case you have to depend on your optimizer to be more sophisticated than in this case.) Second approach is to redefine fill to return a value of type BigStruct2, to be a procedure with an in out parameter of type, or to match the template above. Any of these should work without depending on the optimizer. You may have simplified things in this example to eliminate things like bounds on the component types which are in fact unconstrained array types. In that case it is probably easier on the reader of the code to have function calls with explicit size parameters, but poor optimizers will work better with in out parameters. -- Robert I. Eachus with STANDARD_DISCLAIMER; use STANDARD_DISCLAIMER; function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...