As so often, the
choice depends on (1) the problem you are trying to solve, (2) the skills you
have, and (3) the people you work with (unless it's a solo project). I'll leave
(3) aside for the moment because it depends on everyone's individual situation.
通常情况下，选择取决于(1)你想要解决的问题，(2)你拥有的技能，(3)和你一起工作的人(除非是单独的项目)。我暂时把(3)放在一边，因为这取决于每个人的个人情况。
Problem
dependence: Fortran excels at array processing. If your problem can be
described in terms of simple data structures and in particular arrays, Fortran
is well adapted. Fortran programmers end up using arrays even in non-obvious
cases (e.g. for representing graphs). C++ is better suited for complex and
highly dynamic data structures.
问题依赖:Fortran擅长数组处理。如果您的问题可以用简单的数据结构和特定的数组来描述，那么很适合使用Fortran。Fortran程序员最终使用数组，即使在不明显的情况下(例如表示图形)。c++更适合复杂和高度动态的数据结构。
Skill dependence:
it takes a lot more programming experience to write good C++ programs than to
write good Fortran programs. If you start out with little programming experience
and only have so much time to learn that aspect of your job, you probably get a
better return on investment learning Fortran than learning C++. Assuming, of
course, that your problem is suited to Fortran.
技能依赖:编写优秀的c++程序比编写优秀的Fortran程序需要更多的编程经验。如果你一开始几乎没有编程经验，而且只有那么多的时间来学习工作的这一方面，那么学习Fortran可能比学习c++获得更好的回报。当然，假设您的问题适合Fortran。
However, there's
more to programming than just Fortran and C++. I'd recommend to anyone going
into computational science to start with a dynamic high-level language such as
Python. Always remember that your time is more valuable than CPU time!
然而，编程不仅仅是Fortran和c++。我建议任何想要进入计算科学领域的人从动态高级语言开始，比如Python。永远记住，你的时间比CPU时间更有价值!
I think that both
C++ and Fortran are good enough and work well.
我认为c++和Fortran都足够好，而且工作得很好。
However I think
that Fortran is better for numeric scientific computing, for algorithms that
can be expressed using arrays and don't need other sophisticated data
structures, so in fields like finite differences/elements, PDE solvers, electronic
structure calculations. Fortran is a domain specific language. In particular I
think that it is easier to write fast programs in Fortran than in C++, by a
scientist (not necessarily a computer science expert).
然而，我认为Fortran更适合于数值科学计算，适合于可以使用数组表示且不需要其他复杂数据结构的算法，因此在有限差分/元素、PDE求解器、电子结构计算等领域。Fortran是一种领域特定语言。我特别认为，由科学家(不一定是计算机科学专家)用Fortran编写快速程序比用c++更容易。
C++ is a general
purpose language, so one can express any algorithm in it, and it is most
definitely better for algorithms that can't be expressed using arrays, from HPC
field probably some graphs, mesh generators, symbolic manipulation and so on.
c++是一种通用语言，所以你可以用它来表达任何算法，对于那些不能用数组来表达的算法，它绝对是更好的，从HPC领域可能是一些图，网格生成器，符号操作等等。
It is also
possible to write array algorithms in C++, but in my experience, it requires
much more computer science knowledge and in general more work (i.e. one needs
to create or reuse classes for array manipulation, and handle memory management
by hand or using some library like Teuchos from Trilinos). Non-experts tend to
write pretty good Fortran programs, but horrible C++ programs (talking from my
own experience).
也可以在c++中编写数组算法，但根据我的经验，它需要更多的计算机科学知识和更多的工作(例如，需要创建或重用用于数组操作的类，并手动处理内存管理或使用一些库，如来自Trilinos的Teuchos)。非专业人士倾向于写出相当不错的Fortran程序，但写出糟糕的c++程序(根据我自己的经验)。
Disclaimer: I
personally like Fortran a lot and I prefer it over C++ for numeric computing. I
have spent over 2 years of programming in C++ daily, and almost a year
programming in modern Fortran daily (in finite elements area). I use Python and
Cython a lot too.
免责声明:我个人非常喜欢Fortran，对于数值计算，我更喜欢它而不是c++。我每天用c++编程超过2年，每天用现代Fortran编程近1年(在有限元领域)。我也经常使用Python和Cython。
I couldn't
disagree with this response more. Our finite element code would not have been
possible to write in Fortran. In fact, it started 15 years ago as a mix of
plain C and Fortran (the latter being for the numerically intensive parts of
the method), and it gradually moved to pure C and then to C++ over the course
of several years. The code got consistently shorter, faster, and easier to
understand, and it was more capable after each iteration. I agree with others
that point out that C++ gives you plenty of rope to shoot yourself with. Pick
the language you're most comfortable with. – Bill Barth
我完全不同意这个回答。我们的有限元代码是不可能用Fortran编写的。事实上，它开始于15年前，是普通C和Fortran的混合(后者用于该方法的数字密集部分)，并在几年的过程中逐渐转向纯C，然后转向c++。代码始终变得更短、更快、更容易理解，并且在每次迭代之后都更有能力。我同意其他人的观点，他们指出c++给了你足够多的空间让你自投无路。选择你最熟悉的语言。——比尔·巴特
I'm also throwing
my two cents in kind of late, but I've only just seen this thread and I feel
that, for posterity, there are a few points that desperately need to be made.
我也有点晚了，但我只是刚刚看到这个帖子，我觉得，为了子孙后代，有几点是迫切需要说明的。
Note in the
following that I will talk about C and not C++. Why? Well, otherwise it's
apples and oranges to compare a full-fledged dynamically typed object-oriented
language with something as static as Fortran. Yes, some modern implementations
of the latest Fortran standards can do more than just that, but very few people
actually use them, and so when we speak of Fortran, we think simple, static,
and imperative language. That's where C is too, so I'll replace C with C++ for
the following.
请注意，下面我将讨论C而不是c++。为什么?否则，将成熟的动态类型面向对象语言与像Fortran这样的静态语言进行比较是完全不同的。是的，最新Fortran标准的一些现代实现可以做的不仅仅是这些，但是很少有人真正使用它们，所以当我们谈到Fortran时，我们想到的是简单、静态和命令式的语言。这也是C的位置，所以下面我将用c++代替C。
First of all, any
discussion of Fortran/C having better compilers is moot. Dedicated C/Fortran
compilers are a thing of the past. Both gcc/gfortran and icc/ifc are just
different front-ends to the same back-end, i.e. your program will be
transformed into an abstract description by the front-end and then optimized
and assembled by the back-end. If you write, semantically, the same code in
Fortran or in C, the compiler will, in both cases, produce the same assembly
which will run just as fast.
首先，任何关于Fortran/C有更好的编译器的讨论都是没有意义的。专门的C/Fortran编译器已经成为过去。gcc/gfortran和icc/ifc都是同一个后端不同的前端，也就是说，你的程序会被前端转换成抽象的描述，然后由后端进行优化和组装。从语义上讲，如果你用Fortran或C编写相同的代码，编译器将在这两种情况下生成运行速度一样快的相同程序集。
This now leads to
my second point: why do we still see differences? The problem is that most
comparisons are made by Fortran programmers trying something in C or
vice-versa. Ever notice how most authors or poets prefer to write in their
native languages? Would you want to write poetry in a language in which you
don't feel completely confident or at home? Of course not... I myself consider C
to be my "native" programming language. I did, however, also spend
three years working in a group that used only Fortran, in which I have achieved
a certain level of fluency. I would, however, never write anything on my own in
Fortran since I'm more comfortable with C and, as a consequence, the resulting
code will be better, whatever you define that as.
这就引出了我的第二点:为什么我们仍然能看到差异?问题是，大多数比较都是由Fortran程序员在C中进行的，反之亦然。有没有注意到大多数作家或诗人都喜欢用母语写作?你想用一种你不完全自信的语言来写诗吗?当然不是……我自己认为C是我的“母语”编程语言。然而，我也在一个只使用Fortran的小组里工作了三年，我已经达到了一定的流利程度。然而，我从来不会自己用Fortran写任何东西，因为我对C语言更熟悉，因此，生成的代码会更好，无论您将其定义为什么。
So the main
difference is in the programmer, not the language. So there are no differences?
Well, not quite. Here are a few examples:
所以主要的区别在于程序员，而不是语言。所以没有区别?嗯，不完全是。下面是一些例子:
SIMD: Whether it's
SSE, SSE3 or AltiVec, if you want to use them in Fortran, you better hope and
pray that the compiler guesses exactly what you want and does it so. Good luck.
In C you generally have intrinsic functions for each architecture, or, more
recently, general SIMD vector types in gcc. Most Fortran compilers will only
use SIMD instructions to unroll loops, but if you have a kernel which works on
short vectors of data in a non-obvious way, the compiler will very probably not
see it.
SIMD:无论是SSE、SSE3还是AltiVec，如果您想在Fortran中使用它们，您最好希望并祈祷编译器能够准确地猜测您想要什么并这样做。祝你好运。在C语言中，通常每个体系结构都有固有的函数，或者最近在gcc中有通用的SIMD向量类型。大多数Fortran编译器只使用SIMD指令展开循环，但是如果您的内核以一种不明显的方式处理短向量的数据，那么编译器很可能看不到它。
Different hardware
architectures: The whole CUDA architecture is built around kernels in C. Yes,
the Portland Group now has a CUDA-capable fortran compiler too, but it's
commercial, and most importantly, it's not from NVIDIA. Same goes for OpenCL,
for which the best I could find is a recent project which only supports a few
basic calls.
不同的硬件架构:整个CUDA架构都是围绕c内核构建的。是的，Portland Group现在也有一个支持CUDA的fortran编译器，但它是商业的，最重要的是，它不是来自NVIDIA。OpenCL也是如此，我能找到的最好的是最近的一个项目，它只支持一些基本的调用。
Parallel
programming: Yes, both MPI and OpenMP work just fine with both C and Fortran.
However, if you want real control of your threads, i.e. if you have a fully
dynamic shared-memory computation, you'll be out in the cold with Fortran. In C
you have the standard pthreads which, while not warm and fuzzy, will still get
you through the storm. In general, most computations that rely on access to the
operating system, e.g. threads, processes, file system, etc... are better
served with C. Oh, and don't try to do your own networking with Fortran.
并行编程:是的，MPI和OpenMP都可以很好地与C和Fortran一起工作。然而，如果你想真正控制你的线程，也就是说，如果你有一个完全动态的共享内存计算，你就会被Fortran所冷落。在C语言中，您有标准线程，虽然不温暖和模糊，但仍将帮助您度过难关。一般来说，大多数依赖于访问操作系统的计算，例如线程、进程、文件系统等…最好是用c语言。哦，不要尝试用Fortran来建立自己的网络。
Ease of use:
Fortran is closer to Matlab than C is. Once you've gotten over all the
different keywords and how to declare variables, the rest of the code looks
like Matlab, making it more accessible to users with limited programming
experience.
易于使用:Fortran比C更接近Matlab。一旦您掌握了所有不同的关键字以及如何声明变量，其余的代码看起来就像Matlab，使得编程经验有限的用户更容易访问它。
Interoperability:
When you create a struct in C, the layout of the actual data is
straight-forward and deterministic. In Fortran, if you use pointer arrays or
structured data, the actual layout of the data is strongly compiler-dependent,
not straight-forward, and usually completely undocumented. You can call C from
Fortran and vice-versa, but don't start thinking it may be as easy to pass
anything more than a static array from one to the other and back.
互操作性:当您在C中创建结构时，实际数据的布局是直接且确定的。在Fortran中，如果使用指针数组或结构化数据，则数据的实际布局与编译器密切相关，不直接，而且通常完全没有文档记录。您可以从Fortran调用C语言，反之亦然，但不要认为将静态数组以外的任何东西从一个传递到另一个传递回来是那么容易。
This is all
somewhat geeky, low-level stuff, but this is High-Performance Computing we're
talking about, right? If you're not interested in how to best exploit the
underlying hardware paradigms, i.e. implementing and/or developing algorithms
which are best for shared/distributed memory, threads, SIMD vectorisation, GPUs
using SIMT, and so-on, then you're just doing math on a computer.
这些都是一些低级的东西，但这是我们正在谈论的高性能计算，对吧?如果你对如何最好地利用底层硬件范例不感兴趣，即实现和/或开发最适合共享/分布式内存、线程、SIMD矢量化、使用SIMT的gpu等的算法，那么你只是在计算机上做数学。
联系客服
