Re: IMPLICIT NONE (F2k8+/-)

James Van Buskirk wrote:

"Gary L. Scott" <garyscott@xxxxxxx> wrote in message
news:11ln80341kkhtbd@xxxxxxxxxxxxxxxxxxxxx


IMPLICIT NONE should finally be made default beginning at F2k8.
Compiler switches can be specified to get the older behavior.  There is
absolutely no good reason to continue this way.



But isn't it already as of f90?  I mean to say that in f90
programming, almost all the code is in modules, and typically
one puts an implicit none statement after all the use
statements in the module.  All the module procedures accordingly
inherit the implicit none state from their host module which
must be overridden with implicit statements in each module
procedure if (as is sometimes the case) implicit typing is
actually desired for the given procedure.

A lot of new code is in modules, but I still extensively write static libraries and DLLs that are shared with other applications. Modules do not solve the need to share code with other applications. Modules do not even help much in that area.

--

Gary Scott
mailto:garyscott@xxxxxxx

Fortran Library:  http://www.fortranlib.com

Support the Original G95 Project:  http://www.g95.org
-OR-
Support the GNU GFortran Project:  http://gcc.gnu.org/fortran/index.html

Why are there two?  God only knows.


If you want to do the impossible, don't hire an expert because he knows it can't be done.

-- Henry Ford
.

Relevant Pages

  • Re: IMPLICIT NONE (F2k8+/-)
    ... > All the module procedures accordingly ... > inherit the implicit none state from their host module ... Note that this does not apply to interface bodies. ... but implicit maps are not inherited into ...
    (comp.lang.fortran)
  • implicit is not inherited by use. what else?
    ... showing that implicit statements are not inherited from USEd modules. ... But other things like variables and module procedures are inherited ... end program imptest ...
    (comp.lang.fortran)
  • Re: byte data type
    ... >>That's a good list of byte applications, but I was really searching ... but rather the (implicit) cast from a ...
    (comp.lang.java.programmer)
  • Re: explicit casts
    ... Do not rely on the implicit ... following that recommendation is bad programming. ...
    (comp.lang.c)