l*****s
发帖数: 774 | 1 subroutine和子函数function有什么区别？
感觉subroutine比子函数function用起来方便不少？
是不是这样得？ | t*******y
发帖数: 637 | 2 确实方便一些
一般用subroutine用的多得多吧
【在 l*****s 的大作中提到】
: subroutine和子函数function有什么区别？
: 感觉subroutine比子函数function用起来方便不少？
: 是不是这样得？
| t***l
发帖数: 533 | 3 一般复杂的用subroutine，
简单的用function。
对于返回简单值，频繁使用的时候
function用起来简单一点
【在 l*****s 的大作中提到】
: subroutine和子函数function有什么区别？
: 感觉subroutine比子函数function用起来方便不少？
: 是不是这样得？
| O******e
发帖数: 734 | 4 There are some differences.
Since functions can be invoked in-line, functions with side-effects are not
allowed to be used in certain ways. Metcalf and Reid give two examples on
page 83 in Fortran 90/95 Explained, which are basically:
! func(z) might not be evaluated if x > y, so if func(z) normally modifies z,
! the value of z is undefined after execution of the following statement
x > y .or. func(z)
! since the order in which func(x,y) and func(y,x) are evaluated must not
! matter, func() m
【在 l*****s 的大作中提到】
: subroutine和子函数function有什么区别？
: 感觉subroutine比子函数function用起来方便不少？
: 是不是这样得？
| t*********r
发帖数: 8 | 5 These are actually pitfalls of fortran functions.
Good programming is that you should NOT modify the arguments of a function.
Whereas fortran allows you to do that, you should NOT.
not
z,
【在 O******e 的大作中提到】
: There are some differences.
: Since functions can be invoked in-line, functions with side-effects are not
: allowed to be used in certain ways. Metcalf and Reid give two examples on
: page 83 in Fortran 90/95 Explained, which are basically:
: ! func(z) might not be evaluated if x > y, so if func(z) normally modifies z,
: ! the value of z is undefined after execution of the following statement
: x > y .or. func(z)
: ! since the order in which func(x,y) and func(y,x) are evaluated must not
: ! matter, func() m
| c****w
发帖数: 565 | 6 something called 'interface'...
【在 t*********r 的大作中提到】
: These are actually pitfalls of fortran functions.
: Good programming is that you should NOT modify the arguments of a function.
: Whereas fortran allows you to do that, you should NOT.
:
: not
: z,
| O******e
发帖数: 734 | 7 I agree it is not good practice.
Out of curiosity I tried using functions with side effects in those two
examples given by M&R, and even declared explicit function interfaces
to tell the compiler about the intent(inout) arguments. The Intel compiler
does not detect the problem, and gives different values if I reverse the
two function calls in the max() example.
【在 t*********r 的大作中提到】
: These are actually pitfalls of fortran functions.
: Good programming is that you should NOT modify the arguments of a function.
: Whereas fortran allows you to do that, you should NOT.
:
: not
: z,
| t*********r
发帖数: 8 | 8 en. i just did similar tests on a Mac with xlf, on an XD1 with pgf and on an
Altix with ifort.
i put the func in a module.
as expected, the compilers don't complain; however they don't do what you '
intend' to do.
the executables from ifort and xlf gives one result, the executables from
pgf gives another!
compiler
【在 O******e 的大作中提到】
: I agree it is not good practice.
: Out of curiosity I tried using functions with side effects in those two
: examples given by M&R, and even declared explicit function interfaces
: to tell the compiler about the intent(inout) arguments. The Intel compiler
: does not detect the problem, and gives different values if I reverse the
: two function calls in the max() example.
| O******e
发帖数: 734 | 9 I usually make my functions explicitly pure or elemental anyway,
so as you mentioned, free of side effects. Then there are no
such pitfalls to worry about.
an
【在 t*********r 的大作中提到】
: en. i just did similar tests on a Mac with xlf, on an XD1 with pgf and on an
: Altix with ifort.
: i put the func in a module.
: as expected, the compilers don't complain; however they don't do what you '
: intend' to do.
: the executables from ifort and xlf gives one result, the executables from
: pgf gives another!
:
: compiler
|
|
