[quote][quote][quote][quote]我用的是windowsXP系统，编译器是CVF6.6[/quote]
先搞清楚什么是IDE，什么是编译器
然后google一下，怎样在windows下使用gnu make，关键词提示：msys[/quote]
并不是必须要用make，有折腾gnu make那功夫，还不如花些时间看看项目为什么报错。fortran一般很少存在平台移植性问题。[/quote]
看来你接触的太少了。
fortran跨平台很多都是用预处理的。

只能这样说，只有不考虑宽泛应用要求，不考虑跨平台，不考虑使用api，不考虑预处理，不考虑跨编译器处理，不考虑第三方库，不考虑废弃性标准，那么很少存在移植性问题。[/quote]
第三方库的确会产生此类麻烦，其它的根本不是问题，除非一个有特殊嗜好的程序员，否则很少会写出那样不通用的程序。因为预处理一般是有标准写法的，不同编译器也会遵循相同的标准，至于废弃标准，与跨平台无关、而且大多编译器向下兼容

不是有特殊嗜好的程序员，而是现在各个fortran编译器都有自己的扩展和遵循不同的标准，无法做到真正的统一。
你能说gcc/gfortran的编写代码者，都是你说的有特殊嗜好的一族？

我根本没有说用什么样的编译器编译代码就是特殊嗜好，各个fortran编译器都有自己的扩展和遵循不同的标准毕竟少数，避免用这些特殊扩展肯定是一个优秀程序员要考虑的

[quote]我根本没有说用什么样的编译器编译代码就是特殊嗜好，各个fortran编译器都有自己的扩展和遵循不同的标准毕竟少数，避免用这些特殊扩展肯定是一个优秀程序员要考虑的[/quote]
少数？恩，就算少数吧。看来我用的和知道的都是少数。

一个优秀的程序员应当是即使使用了特殊扩展，也能在其他编译器上通过的程序员。

[quote][quote]我根本没有说用什么样的编译器编译代码就是特殊嗜好，各个fortran编译器都有自己的扩展和遵循不同的标准毕竟少数，避免用这些特殊扩展肯定是一个优秀程序员要考虑的[/quote]
少数？恩，就算少数吧。看来我用的和知道的都是少数。

一个优秀的程序员应当是即使使用了特殊扩展，也能在其他编译器上通过的程序员。[/quote]
我也不说啥了，既然能在其他编译器通过，何谈移植。
没人闲的没事找一些特殊功能，完后再想办法让它通用化，fortran程序一般用来干啥，我想你比我清楚多了，通用的标准足够……

看来你没有一点儿移植的概念

比如说你要在ivf/gfortran使用ABORT，怎么样在一个文件里同时处理呢？

使用预处理即可
#ifdef intel
    USE IFPORT
#endif
call ABORT ("Out of here!")

标准不想再争论，即使是C语言，各个标准之间也是如此处理的（特别是VC还不完全支持C99），何况Fortran近年来冒出一群标准。

你的意思应该是我会一种标准足够，我也不会使用超出或者不支持该标准的编译器。那么这就是你所谓的“通用的标准”。

哪对哪错，看的人都明白，“何况Fortran近年来冒出一群标准”，我就不说啥了

[quote]哪对哪错，看的人都明白，“何况Fortran近年来冒出一群标准”，我就不说啥了[/quote]
难道不对吗？
这只是一个方面，标准还有不完全支持一说，这个是最烦恼的。

[quote]哪对哪错，看的人都明白[/quote]
我们是建立在跨平台移植的情形下说的，你不要偷换概念。
[quote]我就不说啥了[/quote]
我可以理解你是哑口无言了吗


再者，我不太同意要学习什么标准之说，如果你只用一种编译器，那么看编译器文档足矣，如果你用多种编译器，那么应该知道什么语法被这些编译器都支持，如果使用扩展不可避免的话，那么请参考我前述的预处理方法。

[quote]
再者，我不太同意要学习什么标准之说，如果你只用一种编译器，那么看编译器文档足矣，如果你用多种编译器，那么应该知道什么语法被这些编译器都支持，如果使用扩展不可避免的话，那么请参考我前述的预处理方法。[/quote]
正是因为我们要在多编译器编译，所以要明白哪些是ISO Fortran Working Group定义的国际标准，哪些编译器自家的扩展，至于说编译器对新标准功能的支持那都是时间问题。毕竟很多最新的2003/2008标准才出来没几年。
也正如你所说，那些扩展只有在不得已的时候才使用，因为那些不仅仅增加代码量，也减弱代码的可读性、通用性。我们编程序是为了实现功能，而不是为了耍酷。
标准方面我就知道77、90/95、2003/2008（前面的老版本我就不提了）。至于你所说的一大堆，我还真想听听都是那些，开开眼界。

[quote]标准方面我就知道77、90/95、2003/2008[/quote]
难道这个不够一群吗？况且是现在都在使用。其他语言的老标准很多都已经废弃了，最多并轨2种标准。
标准化只是为了统一语言而已，但由于历史上的原因，还是遗留了大量的方言。怎样能充分使用这些代码，是个值得研究的课题。比如Lapack/Blas原始导出，正在慢慢作出更改，使得语法上更贴近F90/F95的写法，这也是个缓慢的进程。
Fortran作为算法语言，标准化跨越的太大也并不是好事，有人要实现完全的面向对象，这个也完全是得不偿失（由于完全的OO不允许重名，会有冗长的前缀在目标代码中，那么将会面临速度的下降和使用内存的急剧增加，所以现在F2003的模拟OO，还是值得继续实行的）。并且由于它的算法特性，也并不适于作为单一编程语言，所以混合编程几乎是Fortran的必由之路。所幸F2003增加了ISO_C_BINDING，解决了在跨平台中跨编译器混合编程符号不相同的问题。
语言只是思想的载体。Fortran作为专注于算法的语言，一切以提高算法可用性和效率性的做法都是值得实践的，但这个并不是拘泥于某个标准的。如果标准未实现怎么办，查看他的语义，然后自己去实现它才是绝佳的途径。你可能会说，过几年编译器都会支持最新的标准，这个可能吧（比如VC2010对C99大部分都不支持，C99已经出来很多年了），但对目前来说，全部更换使用新语法还并不现实，我只希望当前个人编写的代码最多到F2003，这个也是主流编译器大部分实现的标准。
Fortran的未来也是值得让人思考的，我觉得Fortran原生加入内嵌汇编/SIMD编程/OpenCL应该是个可选的路子，虽然现在也可以通过混合编程来实现。正是由于预处理开关的不统一，Fortran应该加入预处理的原生支持，这样会使得适用范围更广些。同时，预处理技术也是C作为跨平台可移植性最强的语言的特性（Java不算，因为需要JVM），Fortran加入这个，可以真正的做到跨平台使用更好的性能特征。
[quote]特殊嗜好[/quote]
[quote]各个fortran编译器都有自己的扩展和遵循不同的标准毕竟少数[/quote]
[quote]没人闲的没事找一些特殊功能[/quote]
[quote]哪对哪错，看的人都明白[/quote]
[quote]我就不说啥了[/quote]
[quote]开开眼界[/quote]
好像你说了那么多，没有什么实质性内容嘛。
最后那个编译器扩展我也不是作为重点来说的，似乎你每句都提。我的意思是如何在一个代码里写出F90/F2003并轨的标准来（只是作为一种可能性）。
时间问题总是被作为托辞，为何不正视现状呢？是环境依你而变化，还是你为了外界环境而做出更改？
同时，我也不知道你为什么认为Fortran调用系统api为什么就是耍酷，这样你会遭到臭石头GG的BS。
实现功能很好啊，但是实现更好的功能不更好吗？

我想说，不要以自己的认知水平作为智慧的极限。你说的，我也没说错误，只是说不太合适，你为啥总是全盘否定我的说法呢？