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,c81dfd55bff3db44 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!postnews.google.com!u3g2000prl.googlegroups.com!not-for-mail From: Adam Beneschan Newsgroups: comp.lang.ada Subject: Re: Record aggregates assignments and the black-box and else Date: Mon, 10 May 2010 08:20:08 -0700 (PDT) Organization: http://groups.google.com Message-ID: <314c8794-dbce-4fe1-b8d8-1258c782fbfe@u3g2000prl.googlegroups.com> References: NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1273504809 14244 127.0.0.1 (10 May 2010 15:20:09 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Mon, 10 May 2010 15:20:09 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: u3g2000prl.googlegroups.com; posting-host=66.126.103.122; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; WOW64; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30618),gzip(gfe) Xref: g2news2.google.com comp.lang.ada:11447 Date: 2010-05-10T08:20:08-07:00 List-Id: On May 7, 2:23=A0pm, Yannick Duch=EAne (Hibou57) wrote: > If I do : > > =A0 =A0 R :=3D (A =3D> R.A, B =3D> 5); > > what is the most likely expected impact on the executable code efficiency= , =A0 > providing this kind of construct oftenly appears in multiple places of th= e =A0 > source ? (the record type is obviously private and just accessed in the = =A0 > implementation). > > Do you think most compilers will use the presence of an R's self componen= t =A0 > as an hint for some kind of optimization when applicable ? This isn't as simple as it looks. The language semantics demand that for an aggregate, the program creates a temporary object of the type whose value is the aggregage; then it assigns R to that temporary object. One consequence is that if an exception is raised while building the temporary object, R will be unaffected. (There are exceptions. If controlled types are involved, I think that compilers are allowed or required to generate code that builds the aggregate directly in R instead of using a temporary object. Also, if Record_Type were limited, you couldn't do the assignment, but an aggregate in some other contexts would *not* cause a temporary object to be built. I don't feel like going into details right now.) I'm not sure what happens in a case like this: R :=3D (A =3D> R.A, B =3D> 5); where R was previously uninitialized. Even though R.A is supposed to have subtype "Natural", if it's uninitialized and thus garbage, it could have a negative value. Thus, it's possible that this assignment, which is conceptually part of the assignment that creates the temporary object: Temp_Object.A :=3D R.A; could raise an exception if R.A happened to have a garbage negative value. However, I don't think compilers are required to generate code that checks this. Since both sides are supposed to be "Natural", the compiler can do the assignment without any checking, and is not required to check that the value on the right side is valid. Anyway, assuming that the compiler determines that R.A will not raise an exception, and that B =3D> 5 cannot raise an exception either, and there aren't any other reasons why R has to be preserved while the temporary object is being created, it might decide that there's no reason to create a temporary object. This is permissible since the semantics would be exactly the same in all cases. Then it's conceivable that the compiler could generate code that looks like R.A :=3D R.A; R.B :=3D 5; and then, in its optimization process, notice that the first assignment is useless. So it's possible that a compiler may optimize the code in the way you were suggesting. However, the compiler does need to do a fair amount of checking to determine that a temp object is unneeded, and there may be compilers that don't do all that work. So I guess the answer to your question is probably that some compilers will optimize the way you want, and others won't. -- Adam