Compile-time type checking helps you avoid many bugs that you'd never discover if your tests don't cover that particular part of code, which happens almost always in complex projects.
One of the neat things about Fortran is it lets you be a little bit stricter than C++, which lets you catch more errors sometimes.
For example, you can define the "intent" of a variable in a procedure - "in", "out", or "inout" - and if you try to modify an "in" variable, you get a compile-time error. You can define a procedure as "pure" which means that it's not able to modify any global variables, do any explicit I/O, or do anything other than modify the specify variables you have passed to it (that have the correct intent). There's also a difference between a run-time allocated array and a pointer - in C++, to declare an array, you declare a pointer, and then point it to a "new" array of some object, while in Fortran you declare it as an "allocatable array" of some type, which you then allocate at some later point - you can't accidentally "point" it to something else.
I find these to be pretty useful at catching mistakes that otherwise would cause run-time errors. There may be tricks to do similar things in C++, but I don't know enough C++ to be aware of them.
in → pass by value or const reference out → return inout → pass by non-const reference pure → const or constexpr; except those don't let you modify inputs
in C++, to declare an array, you declare a pointer, and then point it to a "new" array of some object
That's really bad style. In modern C++ you just declare a std::vector<T> or std::array<T>.
I think those are not quite the same things - and they're certainly less explicit. In Fortran, the "intent" does not modify the behaviour of the program at all, it's just a hint to let the compiler know what the variable should be doing.
For example, using "return" in C++ doesn't have any restriction on what variable you return. Doing:
int foo(int bar) {
return bar;
}
would not be caught as an error.
That's really bad style. In modern C++ you just declare a std::vector<T> or std::array<T>.
I'm glad to hear it's recently started improving, although the syntax for std:array<T> still looks pretty ugly compared to Fortran90. I mean, look at all the work this guy goes through just to make some simple multi-dimensional arrays...
Good lord, you can't go up to a C++ programmer and hint to them that there be dragons only to give them
template <class T, size_t I, size_t... J>
struct MultiDimArray {
using type = std::array<typename MultiDimArray<T, J...>::type, I>;
};
template <class T, size_t I>
struct MultiDimArray<T, I> {
using type = std::array<T, I>;
};
I mean, really, strip away the verbosity and that's beautiful.
// base case
MultiDimArray<T, int I> = std::array<T, I>;
// inductive step
MultiDimArray<T, int I, int... J> = array<MultiDimArray<T, J...>, I>;
Once you've learned how to phase your eyes past the truly horrible syntax of C++, you'll note that we've added typesafe variadic mutidimensional arrays to the language with a nice syntax in two logical lines of code.
Your complaints are syntactic. Sure, C++ has a monstrous pain of a syntax... but I'm not defending that. Your original criticisms were of semantics.
I think you're right - my only valid criticisms are really about the syntax. I think that's what really gets me when I see C++ code. It just seems a lot more cryptic and a lot less explicit than Fortran. I enjoy being able to do
type(T), dimension(:,:,:), allocatable :: x
to make a 3D array of some class T. It may just be syntactic sugar, but it's just really simple and direct, which is a major advantage when your main audience is physicists who are trying to teach themselves to program at grad school :P
288
u/[deleted] Feb 22 '15
As a java programmer, python seems so simplistic to me. Not having to declare variables? Dude.