[Proj] Building for and calling from g95-MinGW

[Jan Hartmann]

Gerald I. Evenden wrote:
> On Wednesday 18 February 2009 7:01:00 am Jan Hartmann wrote:
>   
>> Long ago, I did this using named common blocks and extern C structs. Why
>> won't you use named common blocks? I understand the dangers of the
>> unnamed common, though.
>>
>> Fortran 90 seems to have more possibilities for data representation. I
>> never worked with it, but see an example at:
>>
>> http://gcc.gnu.org/ml/gcc-help/2008-01/msg00170.html
>>
>> Jan
>>     
>
> My original question was not a particularly serious one and I was only 
> interested if there was a trick to using FORTRAN that I was unaware of when 
> dealing with C[++] structures.
>
> I am aware of the 'common' usage and that was why I was trying to excude it 
> from the conversation.  'common' is quite restrictive compared to general 
> usage of passing structures and pointers through program processes.
>
> The only other point that I would make about intermixing FORTRAN and C[++] is 
> that I would only consider using C as the entry mechanism and any FORTRAN 
> code would be processes called by C.
>
> Because of my personal history of starting with machine language and then 
> graduating to Balgol 58 and then Algol 60 before being sent into the 
> purgatory of what I call the "Dark Ages" where I was forced to use FORTRAN 
> for several years, I have a rather jaundice opinion of the language.
>
>   
I had the singular luck to have started programming around 1980 with a 
procedural language: Simula 67, an extension of Algol 60. The nicest 
thing about it was that it had the "Class" concept, a mixture of structs 
with function, that got popular with C++ and later 5th generation 
languages like Java and Javascript, only much simpler. People *will* 
make simple concepts as complex as they can, won't they? It was really a 
beautiful language for learning purposes, and I never understood why it 
more or less disappeared. It's unbelievable how much profit I still 
have, even today, from starting off with that language, if only from not 
being tempted to use faulty programming practices. And then, I knew what 
a class was around 1980, when almost everyone was still struggling to 
debug Common Blocks, unnamed or not. It's still available on Internet I 
believe.

I only have used Fortran when nothing else would do, especially in 
linking libraries (like NAG) or with parallel computing. In my Simula 
days, a program compiled with Fortran ran three times as fast as a 
Simula program, so I translated my 3D visualisations line for line from 
Simula (or Pascal) into Fortran. They had to run in 1M of internal 
memory too (16 M if you ran them at night and used all the resources of 
the University computing center), so some kind of optimization was 
required. Funny things happen when you corrupt a common block, and send 
the code to a pen plotter. It goes absolutely haywire, and the Computing 
Center won't be amused. So I hated it! Switching array dimensions in 
multidimensional arrays when interfacing Fortran to C may seem simple 
(it is, conceptually), but *will* run you into impossibly hard to find 
bugs, like running a complete Computing Center to its knees, no matter 
how careful you are.

I really don't see any reason nowadays to program in Fortran, not even 
Fortran 90 (although I don't know that), but parallel processing. Don't 
know much about that either, but I followed a course here in Amsterdam 
at SARA computing center, and it still seems easier to optimize parallel 
programs written in Fortran than in any other language. From what I saw 
of those parallel programs (like weather forecasts) didn't look all too 
complex to me from a programming point of view, just a few differential 
equations that were repeated zillons of times. I did some user interface 
programming, and it would be fun to see that done in Fortran. Well, fun 
if you really hated the person...

Jan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20090218/3fef4853/attachment.html>