Lahey Support
08-15-2003, 01:33 AM
This exchange of frustrations (B.Tangren/T.Zies) eshould simply
not be happening.
A compiler and linker should not only trap errors but explain
the situations found quite clearly.
If possible, automatic correction action should be taken and
warnings issued.
For example, something is found that a switch setting should have cured,
then the appropriate switch setting that would cure this
SHOULD BE ASSUMED and again, a warning noted.
(I don't like such switches anyway. I want an equivalent
compile option command in the source text).
If there are missing external references, perhaps a library
search in the obvious places should be tried. And the User's
manual should have a large section on "How to..".
Tangren is trying to do something reasonable and probably common;
using C code or functions to overcome current Fortran rigidity.
I sit here, smugly using an old fortran compiler that NEVER
gives me problems, because it gives very clear textual explanations
of what was wrong. Actually it is difficult to cause errors in
the compile phase because things remain simple, but any runtime
errors are clear too.
(e.g. exceeding the length of an internal write string, or an incompatible
format statement). These are STILL the "good old days".
Why should I (or any other user) not expect the same now from
newer compilers? Or even better given that F90/95 supposedly
makes it more difficult to make run-time errors?
Again, is this likely to get neophites trying Fortran?
This is a communication problem!
(By the way, I just wrote a fully general file sort/merge in
Fortran 77 without exceeding 16 open files, which works in DOS
in ANY Windows/DOS version! This solves MY problem).
Terence Wright
----------------------------------------------------------
To unsubscribe, send to [address removed] the following
as the first and only line of the message body:
unsubscribe fortran
----------------------------------------------------------
not be happening.
A compiler and linker should not only trap errors but explain
the situations found quite clearly.
If possible, automatic correction action should be taken and
warnings issued.
For example, something is found that a switch setting should have cured,
then the appropriate switch setting that would cure this
SHOULD BE ASSUMED and again, a warning noted.
(I don't like such switches anyway. I want an equivalent
compile option command in the source text).
If there are missing external references, perhaps a library
search in the obvious places should be tried. And the User's
manual should have a large section on "How to..".
Tangren is trying to do something reasonable and probably common;
using C code or functions to overcome current Fortran rigidity.
I sit here, smugly using an old fortran compiler that NEVER
gives me problems, because it gives very clear textual explanations
of what was wrong. Actually it is difficult to cause errors in
the compile phase because things remain simple, but any runtime
errors are clear too.
(e.g. exceeding the length of an internal write string, or an incompatible
format statement). These are STILL the "good old days".
Why should I (or any other user) not expect the same now from
newer compilers? Or even better given that F90/95 supposedly
makes it more difficult to make run-time errors?
Again, is this likely to get neophites trying Fortran?
This is a communication problem!
(By the way, I just wrote a fully general file sort/merge in
Fortran 77 without exceeding 16 open files, which works in DOS
in ANY Windows/DOS version! This solves MY problem).
Terence Wright
----------------------------------------------------------
To unsubscribe, send to [address removed] the following
as the first and only line of the message body:
unsubscribe fortran
----------------------------------------------------------