I am wondering to what extent Fortran is being used by quants.It does produce very fast code and it does have some object oriented capabilities.For standalone programs that provide taylored solutions to specific problemsit would seem to be a good choice.

You can use Fortran under .NET which makes it easy to integrate it enterprise wide.Fortran in .NETRegards.

There are still a number of routines available in Fortran, but it is hard to tink of anything very useful that isn't available in C++.Broadly, C++ code will end up going faster than Fortran, however optimising solely for speed in either languages means departing from anything resembling O-O.The only reason I can create for using Fortran is to produce code that only you understand, so they dare not sack you.To do it properly, use Watfor or watfiv preprocessors, and you can get code obfucated out of sight.

trc,I think it very much depends on the firm. I have no idea how widespread it is in QF, but I do know that one of our PhD students just got a job at an energy trading firm and two of his big selling points were that he had knew Fortran9x and he had written a significant app (~1500-2000 lines) in Fortran.My own personal opinion is that its a great language, it allows those who are not programmers to build apps quite quickly, that do run quickly. And although DCFC and I could go back and forth about what language produces the fastest code, at the end of the day, compilers matter more than languages for speed. If you must write C/C++ and care about speed, then buy a compiler which cares about speed. (such as Intel) That is one difference between Fortran and C/C++ compilers. Speed is a primary concern to _all_ Fortran compilers, and I think it gets much less attention with most C/C++ compilers.I will flatly contradict him on one point, though, and that is that using OO will slow down Fortran. One of the strengths of Fortran is that the language standard is written specifically with optimization in mind. Adverse optimization impact is one of the primary reasons that various langauge modifications are voted down. On the flip side, because optimization is such a priority, many of the most useful OO concepts are not available in Fortran (function pointers, for one, though there are many others, and about 75% of these are in the newest language revision, Fortran200x).To reiterate, I defer to others about how widespread Fortran's use is. I know that it's use is not zero, but it is certainly less than C/C++, though I still don't know why... Matt.

will flatly contradict him on one point, though, and that is that using OO will slow down Fortran. Not quite what I meant, indeed to an extent I was more thinking of how things like virtual functions et al in C++ impose overhead.OO does lead you away from writing efficient code, whatever the language. The obvious example is sharing data. An OO programmer will wrap a data object with accessor functions. Someone desparate for speed will share data between any function that feels the need to use it. An OO programmer will quite reasonably write his higher level code in a way that does not care about how it is represented. Again this means he does not squeeze out the performance gains to be had from knowing exactly what bits are where.Bunging things on stacks consumes processor cycles, making function calls far more expensive than just leaving variables lying around in the global area where anyone can get at them. Extensive use of globals mean that if two functions share intermediate results you can avoid evaluating them.None of these optimisation techniques make for greater stability, and maintaining such code can be truly awful, which is of course why we invented OO and structured programming. However, they come at a price of slower systems.I'm vaguely surprised that function pointers were seen as something that would slow Fortran down. I've used them in C to speed things up. Is this because optimisation may cause bad things to happen ?There will always be a market for fortran, simnply because some people have invested impressive amounts of money in system based upon it. Thus they need people to keep it moving forward.

QuoteI'm vaguely surprised that function pointers were seen as something that would slow Fortran down. I've used them in C to speed things up. Is this because optimisation may cause bad things to happen ?Its a CPU/instruction pipeline/branch optimization issue. The hardware can't predict (and prefetch) the different possible instruction locations when the location of the next instruction is the then current value of a register or memory location. With simple call/return or if/else type branching, the CPU can prefetch both possible execution paths.

A possible use of Fortran written code is the vast number of numerical algorithms written in Fortran, e.g. for optimization, linear algebra etc. The f2c converter can be used for converting Fortran code into C code that is hardly readable but likely to compile on a number of C compilers.It is of course possible to link C or C++ code with Fortran compiled code, but portability can be very difficult, especially if the code is to work on both Windows and Unix platforms. C (function) pointers can be represented in Fortran (as integers) but can't be accessed. So if your Fortran code calls some C/C++ function returning a pointer, this pointer can be passed to other C/C++ functions. Pointers are represented as integers, but details are platform dependent (from my own experience: C pointers are represented as 4-byte integers on 32-bit SUN machines, and as 8-byte integers on 64-bit Digital Alpha machines - I am not sure whether these two observations are enough for extrapolation to other platforms and compilers)