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: 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!news3.google.com!news.glorb.com!newshub.sdsu.edu!newscon04.news.prodigy.net!prodigy.net!newsdst01.news.prodigy.net!prodigy.com!postmaster.news.prodigy.com!newssvr25.news.prodigy.net.POSTED!4988f22a!not-for-mail From: Newsgroups: comp.lang.ada,comp.lang.fortran,comp.lang.pl1 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> Subject: Re: Ada vs Fortran for scientific applications X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-RFC2646: Format=Flowed; Response Message-ID: NNTP-Posting-Host: 70.134.98.164 X-Complaints-To: abuse@prodigy.net X-Trace: newssvr25.news.prodigy.net 1152630167 ST000 70.134.98.164 (Tue, 11 Jul 2006 11:02:47 EDT) NNTP-Posting-Date: Tue, 11 Jul 2006 11:02:47 EDT Organization: SBC http://yahoo.sbc.com X-UserInfo1: [[PA@SBEQJV]SQ@[EZOD]_\@VR]^@B@MCPWZKB]MPXHZUYICD^RAQBKZQTZTX\_I[^G_KGFNON[ZOE_AZNVO^\XGGNTCIRPIJH[@RQKBXLRZ@CD^HKANYVW@RLGEZEJN@\_WZJBNZYYKVIOR]T]MNMG_Z[YVWSCH_Q[GPC_A@CARQVXDSDA^M]@DRVUM@RBM Date: Tue, 11 Jul 2006 15:02:47 GMT Xref: g2news2.google.com comp.lang.ada:5614 comp.lang.fortran:11937 comp.lang.pl1:1981 Date: 2006-07-11T15:02:47+00:00 List-Id: "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. Richard Riehle