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 autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,7f1e0b399cd01cb0 X-Google-Attributes: gid103376,public From: Robert Dewar Subject: Re: Unreferenced lock variables Date: 1999/04/20 Message-ID: <7fi0uj$k99$1@nnrp1.dejanews.com>#1/1 X-Deja-AN: 468701487 References: <7ero31$n46$1@nnrp1.dejanews.com> <7esrmv$k1n$1@nnrp1.dejanews.com> <3713b417.22324981@news.pacbell.net> <3718268c.48395643@news.pacbell.net> X-Http-Proxy: 1.0 x10.dejanews.com:80 (Squid/1.1.22) for client 205.232.38.14 Organization: Deja News - The Leader in Internet Discussion X-Article-Creation-Date: Tue Apr 20 13:54:29 1999 GMT Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/4.04 [en] (OS/2; I) Date: 1999-04-20T00:00:00+00:00 List-Id: In article <3718268c.48395643@news.pacbell.net>, tmoran@bix.com (Tom Moran) wrote: > Randy Brukardt was kind enough to educate me on some of > the points here, including > procedure Something(P : in integer) is > Unused : integer := P/0; > begin ... > which can legally have Unused eliminated and thus the > divide by zero eliminated. That certainly provides an > analogous precedent for eliminating the controlled > Initialize/Finalize. This is a bad analogy. Yes, I know that some of the ARG members used this to justify the position taken, but the reasoning is faulty. In the case of built-in language checks, the idea is to prevent the program from doing something bad. In other words a divide by zero is an error in your program, and if it happens you want to know about it. We decided early on in Ada 83 that it was OK to eliminate such exceptions if the situation leading to the error can be safely eliminated. There are three reasons here: 1) We really don't want the nice checking in Ada to damage code generation unnecessarily. Programmers want to know if a real error occurs, but they do not need to know EXACTLY where a constraint error is raised, or to know about a CE that in fact was not raised at all for good and sound reasons. 2) If we eliminate the divide in a case like this, we eliminate the error. So the idea of run time checks, to check for errors is not violated by this optimization. 3) A correct program does not raise exceptions like this anyway (if you use divide by zero as a normal case control structure, you should be drummed out of the Ada community!) This means that correct programs are not affected by these kinds of optimizations. Now the initialize/finalize case is TOTALLY different. None of the above considerations applies. In fact this is the thin end of a very dangerous wedge. Here for the first time we have well defined behavior from a program, which we know that existing programs sometimes use for good reasons, and we suddenly introduce a new rule which allows the optimizer to optionally change the behavior of the program in a fundamental way that is incompatible with what is in the RM. This is not what I call an optimization! Yes, there have been discussions of possible optimizations in the case of temporaries created by the compiler, but such temporaries are in some sense an artifact of the implementation anyway. Here we are talking about a declared variable, and it is 100% clear that the current RM requires the initialize and finalize call. Why the thin end of the wedge? Because next someone will say X : Integer := Function_With_Side_Effects; is allowed NOT to call the function if X is unused, and away we go down the slippery slope. A couple of further points here. GNAT will most certainly NOT take advantage of this optimization, it seems a bad idea. If you have no user defined initialization routine, and a finalization routine whose only purpose is to release storage, then you can use the GNAT pragma pragma Finalize_Storage_Only (subtype_NAME); which tells the compiler to omit the Finalize call if it is not needed, e.g. at the outer level, or all the time in a Java environment. Such pragmas that control the behavior of the compiler are legitimate, and I would have no objection to a pragma saying pragma Omit_Initialize_Finalize_For_Unused; but to allow this optimization without such a pragma is to me a language change justified only by the hope that an "optimization" will be significantly worth while (only a hope, no quantitative data of any kind is available!) Robert Dewar -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own