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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,c4cb2c432feebd9d X-Google-Thread: 1094ba,c4cb2c432feebd9d X-Google-Thread: 101deb,15c6ed4b761968e6 X-Google-Attributes: gid103376,gid1094ba,gid101deb,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news1.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: "Alex R. Mosteo" Newsgroups: comp.lang.ada,comp.lang.fortran,comp.lang.pl1 Subject: Re: Ada vs Fortran for scientific applications Followup-To: comp.lang.ada Date: Tue, 11 Jul 2006 18:54:26 +0200 Message-ID: <4hi39sF1qqsigU1@individual.net> References: <0ugu4e.4i7.ln@hunter.axlog.fr> <%P_cg.155733$eR6.26337@bgtnsc04-news.ops.worldnet.att.net> <6H9dg.10258$S7.9150@news-server.bigpond.net.au> <1hfv5wb.1x4ab1tbdzk7eN%nospam@see.signature> <2006052509454116807-gsande@worldnetattnet> <1kzktalo9krea$.z8n9wev45xct$.dlg@40tude.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Trace: individual.net fZ16gn4unBkUFIYibwRtuA+HPT23aYhmsnoNM9y5Tqh8jZjF4= User-Agent: KNode/0.10.2 Xref: g2news2.google.com comp.lang.ada:5621 comp.lang.fortran:11948 comp.lang.pl1:1988 Date: 2006-07-11T18:54:26+02:00 List-Id: Tom Linden wrote: > On Tue, 11 Jul 2006 08:02:47 -0700, wrote: > >> >> "Tom Linden" wrote in message >> news:op.tci16qgszgicya@hyrrokkin... >> On Mon, 10 Jul 2006 23:46:45 -0700, wrote: >> >>> >>> "robin" wrote in message >>> news:z9Dsg.2740$tE5.2374@news-server.bigpond.net.au... >>>> >>>> Compilers can check for uninitialized variables during compilation. >>>> >>> True. In fact, Ada compilers issue a warning for any variable >>> that is used before a value is assigned to it. If a parameter is >>> included in a method (function/procedure/subroutine) and never >>> referenced, a warning is issued. Sometimes the pragma >>> Normalize_Scalars is useful. Often, the correct design is to >>> leave variables uninitialized until they are used so an exception >>> can be raised. However, since the compiler will emit a warning >>> about variables that have never been assigned a value in an algorithm >>> that tries to use it, no harm is really done since the careful >>> programmer >>> will not release a program with warnings in it. >> >> TL>In general, this is not possible, and it is somewhat silly to have the >> TL>compiler issue such messages, because on the average it will be >> TL>wrong as often as it is right. This can not be done at compile-time >> TL>but must be done at run-time and it requires the compiler to >> TL>generate a lot of machinery to produce such mediocre messages. >> TL>Wht we did in PL/I was to produce in the cross-reference >> TL>listing information on where a variable was referenced or >> TL>assigned, but this was also somewhat incomplete because >> TL>it requires a further analysis of aliasing. My view is that it is >> TL>of dubious value. >> TL> >> >> It might be of dubious value in PL/I, but it is quite helpful >> in Ada. These warnings often help with better structuring of a >> program. In a large, complex program, they prevent errors that >> result from simple little oversights we all make in the normal >> course of programming. >> >> These kinds of warnings extend to methods declared, but never >> invoked. For example, in the sample code in the earlier post, >> if I had never used Ada.Integer_Text_IO in my program, the >> compiler would have informed me that I had a package in >> scope that I never used. I have never known the compiler >> to issue a message that was wrong. On the other hand, >> it is a warning, not a fatal error because I really might want >> to use that artifact in a future iteration of my development. >> When I do use it, the warning goes away. I personally >> find this very helpful. Others may find it annoying. In >> the long run, it is a good feature when developing >> safety-critical software where extraneous code is not a >> good thing. > > My comments were not restricted to PL/I, but apply generally to > any compiler, and specifically Ada was intended. Since I had put > in the scaffolding for producing the info in cross reference listings > I also played with generating precisely the sort of warnings that you > refer to, but found it generated too much "clutter" of questionable > value. That was my view, FWIW I have to disagree. Warnings for unused entities have helped me in many instances. Forgotten calls, forgotten updates to loop control variables are the obvious examples. These warnings don't usually reveal subtle bugs that would go unnoticed, but evident errors that would be caught in testing, but this undoubtedly reduces wasted time. In my experience, 90% of these warnings did correspond to a real bug and the rest were due to removed code, so the unused entities could be removed/commented as well, which I prefer. In particular, I know the precise warnings Richard is referring to (I guess we use the same compiler), and they have never been clutter for me. I can't imagine code generating lots of these warnings not being a maintenance nightmare. In general, if compiler warnings are well done, which basically means no false positives that lead to ignoring/disabling them, are another excellent tool for better development. My Ada compiler has never disappointed me in this regard.