Compiler benefits (was: The Industry choice)

Cameron Laird claird at lairds.us
Mon Jan 3 10:08:08 EST 2005


In article <1104689464.828070.309990 at c13g2000cwb.googlegroups.com>,
 <beliavsky at aol.com> wrote:
>Roy Smith wrote:
>>I think you've hit the nail on the head. In awk (and perl, and most
>>shells, and IIRC, FORTRAN), using an undefined variable silently gets
>>you a default value (empty string or zero). This tends to propagate
>>errors and make them very difficult to track down.
>
>You may recall correctly, but Fortran compilers have improved. The
>following Fortran 90 program
>
>integer, parameter :: n = 1
>real :: x,y=2.0,z(n)
>print*,"dog"
>print*,x
>z(n+1) = 1.0
>print*,z
>end
>
>has 3 errors, all detected at compile time by the Lahey/Fujitsu Fortran
>95 compiler, with the proper options:
>
>2004-I: "xundef.f", line 2: 'y' is set but never used.
			.
			.
			.
I wonder how many of Lahey/Fujitsu users ignore the 'I' diagnostics:
"It's not really an error--the program still runs."

I'm a bit grouchy today on the subject of engineering standards.

I think your point was that the checking present in modern Fortran
compilers, or PyCheckers, but absent from core Python, is a net 
benefit.  That I grant.  I'm reluctant to argue for a change in
Python.  I personally prefer to urge PyChecker on developers.



More information about the Python-list mailing list