Fortran Vs C, C++, C#
in [Fortran]
|
Prev: practice online trading. platinum online trading. online trading worldwide. online trading which is best
Next: variant data type
From: Richard Maine on 14 Jul 2010 12:03 Lynn McGuire <lmc(a)winsim.com> wrote: > Are strong typing and function prototypes mandatory in Fortran 90 ? > > You can force typing by adding "implicit none". But is it strong > typing ? Yes. Of course, that's the kind of word that has different meanings to different people, but it is strong typing by the definitions I've most often seen. In particular, textually identical types are not considered to be equivalent; you actually have to use the same type definition rather than copy its text. (Sequence types are an exception, but one can choose an easily enforceable style that avoids them; you have to avoid them to use type extension. See below about style options.) "Function prototypes" is a language-specific term rather than a general concept. The analogue in Fortran would be an explicit interface. Explicit interfaces are mandatory when you use pretty much anything "interesting" in terms of procedure arguments. Perhaps more important than being mandatory is that they are automatic as long as you make it a policy to use modules. If you require that all procedures be module procedures (an easy requirement to enforce), then there can't be a procedure without an explicit interface. Fortran does not go in for mandatory enforcement of programming style by the language spec. It is much more about providing the programmer with options. Many of those style options can be verified/enforced if that is one's inclination. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: Lynn McGuire on 14 Jul 2010 12:17 > Fortran does not go in for mandatory enforcement of programming style by > the language spec. It is much more about providing the programmer with > options. Many of those style options can be verified/enforced if that is > one's inclination. One area where we have had many problems is with programmers failing to declare variables. I also believe that the mandatory enforcement of variable typing in C++ is a big plus. Since we are not using a F90+ compiler, we do not have interfaces but I also think that mandatory function prototypes in C++ is a big plus from my experience. I cannot tell you how many times we have had trouble with subroutine calls in our fortran code because a programmer gave the wrong number of arguments or the wrong type of arguments. So, yes, I think that strong variable types and interfaces (function prototypes) should be mandatory in a computer language. Lynn
From: Lynn McGuire on 14 Jul 2010 12:24 >> You can force typing by adding "implicit none". But is it strong >> typing ? > > About as much as in C++ - i.e. not very, in both cases. But there's > essentially no systematic difference, and only the details of what > you have to do differ. However, the do differ (wildly) and both > have serious loopholes in their type systems. I disagree. C++ forces the programmer to type and will devolve that type into the lowest common denominator that it can. If you are using objects rather than base types (int, double, etc) as types then C++ is very rigid about operations on those variables. The programmer can always cheat by casting but that is very obvious what is going on then. > Trivially. I have a 10x10 matrix, and I want to pass the 4x4 centre > to a routine that expects a normal 4x4 matrix. If you use entirely > modern Fortran (i.e. assumed-shape arrays), that doesn't even copy > the data when doing that. C++ has no equivalent - and, no, gslice > does not cut the mustard. Thanks, yes, that is very true. > In Fortran, if two arguments overlap IN ANY WAY and are not flagged > as potentially aliasing each other, neither may be written to. > That is not the case in C++, so it can't use that for optimisation. Yes. I have run into the memcpy overlap problem quite a few times. > C++ requires all function calls, implicit and explicit, to be executed > in some sequential order. Fortran does not, and they may be reordered > or even omitted. I dont quite understand this example but that is OK. Thanks, Lynn
From: nmm1 on 14 Jul 2010 12:59 In article <i1knum$p0s$1(a)news.eternal-september.org>, Lynn McGuire <lmc(a)winsim.com> wrote: >> Fortran does not go in for mandatory enforcement of programming style by >> the language spec. It is much more about providing the programmer with >> options. Many of those style options can be verified/enforced if that is >> one's inclination. > >One area where we have had many problems is with programmers >failing to declare variables. I also believe that the mandatory >enforcement of variable typing in C++ is a big plus. That's essentially trivial to enforce in Fortran, provided that you have adequate project management. Remember that, UNLIKE C/C++, it is trivial to parse Fortran well enough to check that IMPLICIT NONE is used (as well as that people haven't used single precision by accident, and several other such errors). A very simple Python script will do it. >Since we are >not using a F90+ compiler, we do not have interfaces but I also >think that mandatory function prototypes in C++ is a big plus from >my experience. I cannot tell you how many times we have had trouble >with subroutine calls in our fortran code because a programmer gave >the wrong number of arguments or the wrong type of arguments. Well, if it were the other way round, you would be comparing Fortran 95 with K&R C (and no lint). >So, yes, I think that strong variable types and interfaces (function >prototypes) should be mandatory in a computer language. I agree. But they aren't properly, in either C++ or Fortran. C++ and modern Fortran are a hell of a lot better than K&R C and Fortran 77 in that respect, I agree :-) Regards, Nick Maclaren.
From: nmm1 on 14 Jul 2010 13:05
In article <i1koc0$r0g$1(a)news.eternal-september.org>, Lynn McGuire <lmc(a)winsim.com> wrote: >>> You can force typing by adding "implicit none". But is it strong >>> typing ? >> >> About as much as in C++ - i.e. not very, in both cases. But there's >> essentially no systematic difference, and only the details of what >> you have to do differ. However, the do differ (wildly) and both >> have serious loopholes in their type systems. > >I disagree. C++ forces the programmer to type and will devolve >that type into the lowest common denominator that it can. If you >are using objects rather than base types (int, double, etc) as >types then C++ is very rigid about operations on those variables. >The programmer can always cheat by casting but that is very obvious >what is going on then. I wish :-( As a simple example of where C++ is much laxer than Fortran, consider arrays versus pointers to scalars - in Fortran, they are distinct. And, in a good compiler, array indices etc. are checked at run-time; try NAG Fortran with -C=all. Regards, Nick Maclaren. |