I know there have been many ineresting (but always inconclusive) discussions on comparison between Fortran 77/90 and C++. But ...

Let me ask all of you if there are programs available that convert a running program from one language into a useful program in another language. Any major pros and cons of this? Any major known limitations?

(1). Since I have been writing Fortran code for many years, and I also have been reading many C++ books recently, I will give you my opinions briefly here. (2). In the procedural programming portion, Fortran ( and Basic) and C ++ ( and C) are about the same. (3). So, if you stay away from the use of the pointer ( the variable which sotres the memory address of a variable), it should be possible to write a one-to-one correspondence table look-up of the commands in the languages. In other words, you don't have to learn another language. (4). There is a difference between two languages in handling the argument passing through functions. So, one had to be careful in the mixed-language programming. (5). With the pointer, there are two other ways to pass the arguments through the function(by pointer, and by reference) in C++. (6). In object-oriented programming, C++ can create user-defined structures and classes, with private data and public functions included and then defines objects to perform the necessary tasks in the program. Although, one can simulate the same OOP concept, I thnik, it going to be hard to do the automatic translation. (7). So, if one try to avoid these two areas in programming, it is possible to write a program to do automatic translation. Then, you are not going to have the advantages ( or disadvantages) of using the features such as the pointers and the classes. (8). As for Fortran-90, I can't comment on it because I have not used it up to now.

Hi, thank all of you for the comments and suggestions on this topic that I put on before. Now I am trying to write my code in C++. Here, I'd like to continue this thread a little further. Is that to say that it is easy to translate a programm in Fortran into one in C++? For the features of OOP, such as pointer, class, and inherritance, what is the main advantages of them in CFD programming.

Raza,

let me try to answer your question concerning a conversion program. yes indeed there exist such a program and it called f2c or therelike. it converts a fortran77 code into c. but don't be too much excited...it does its job pretty well but make sure you are experienced in both languages because you will definitely have to modify your c code afterwards.

thomi

Yes. AT&T's f2c will do it for you automatically. The code will be slower (expect about half speed) and need some reworking to make semi-readable.

A pointer has nothing to do with OOP. It also has nothing to do with describing the problem to be solved. It is simply an implementation/bookeeping construct that any reasonable programming language avoids. It arises in C++ because of maintaining compatability with the high-level assembler C. There is no advantage for CFD programming. All modern languages (and most ancient languages) do not waste the programmers time with the explicit use of pointers. The latest language from the AT&T group which brought you unix, C, C++, etc. have also dumped pointers (and inheritance).

The use of the word class varies significantly from language to language. Experience indicates that grouping together data and methods that act on that data is a good way of organizing the task of programming. It can be done in any language but the language constructs like the C++ class are certainly beneficial compared with, say, organizing a Fortran program along these lines (personal experience). There can be a small performance penalty but a large structural benefit. A good thing.

The benefits of inheritance are less clear cut for numerical analysis although a key concept in OOP. The use of virtual functions in C++ is again an implementation orientated concept (like pointers) rather than a problem solving one. Their partial use in classes leads to a large number of obscure problems. Minimising a numerical programs reliance on inheritance is probably wise.

Templates (which you do not mention) are a much more useful programming concept for numerical programs. Unfortunately, most C++ compilers only partially implement them and their use can lead to massive binaries and absurdly long compile times. It seems to be hard to come out in front using C++!

(1). After reading many books in C++, I think, the biggest problem with C++ is not that it is difficult to learn but because it is not properly introduced to the user. (2). And the main reason behind is that these C++ books are all written by programmers. (3). It would be easier to show the user the need, the problem and the C++ sample solution directly instead of using the new words of class, object, data encapsulation, class inheritance, virtual function, etc...

I cannot see how C++ can be presented as anything other than what it is - a big complex programmer's language. It is also meant for programming reasonably large programs where the benefits of the program structure outweigh the extra coding.

Most of the words you list are defined outside the C++ world, used by most other OOP languages and understood by programmers. Their meaning is adapted slightly to fit how C++ works but the other languages do this also. They are not new words in the sense that C++ invented them.

I can assure that C++ takes a considerable time to master. Not so much what the statements apparently do but what else the compiler is doing (over which one has only modest control and so your program has to go along with it) and how to turn it into a "higher level" language suitable for efficiently solving your problems. The latter usually rests on suitable (and efficient) packages of classes which take a lot of time and effort to develop. Inevitably, one must look to others to provide these packages leading to long term strategic problems (although people using the traditional Windows approach do not seem to be bothered about this! - apologies). This is exacerbated by the language itself which is still evolving in fairly fundamental ways and every "C++" compiler is different.

In time, given the baffling popularity of C++, it is not unreasonable to hope that what "C++" is can be agreed upon by the compiler suppliers and, possibly, the people defining the language. If/when this happens a wide range of stable class packages should appear making the language much more suitable for people wanting to use it to efficiently define and solve their computational problems.

A better solution for CFD purposes (although probably not everyone's) would be for C++ to dump compatability with C, dump a large proportion of the language, and keep simple classes and a powerful type system (templates that really work). This, of course, would not be in the spirit of C++ and not have a long list of features to hype but we can dream.

An even better solution would be for microprocessors to provide a bit of hardware support for functional languages (move some of what have to do with software statements into the hardware) and then we could be really moving. Small, reliable, implicitly parallelizable programs... But where is the business case? I guess I really am fantasizing now.

(1). Almost all of the c++ samples listed in C++ books are small programs. They are typically one page long. So, it does not have to be a large program environment. (2). I would say that a combination of the procedual approach and object-oriented approach is a good approach. In the real world, the action to do something is normally sequential (exclude the brain function naturally), and the person, the bank account, the car, the solver are typically object-oriented. In other word, the approach is practical and it avoid un-necessary problems, such as a person's fuel tank, or a car's bank account. (3). Along this OOP (object-oriented programming) approach, one can define a class called " class duct2d " for a general CFD program to solve any 2-D duct flow. Inside the duct2d class, we need to put in arrays of velocity, temperature, etc. as private data members. These should be 2-D arrays, something like vx[imax][jmax], vy[imax][jmax], t[imax][jmax],.... (4). Then the public member functions can be included as geom_mesh(), init(), boundary_conditions(), mesh_display(), solv(), output_display(), etc.. to read in wall geometry and generate mesh, to provide initial flow field, to set boundary conditions, to display the geometry and the mesh, to solve the equations, and to display the results. (5). The main function of the program can be written as int main() { duct2d myduct; myduct.geo_mesh(); myduct.init(); myduct.boundary_conditions(); myduct.mesh_display(); myduct.solv(); myduct.output_display(); return 0 }. This is like saying that, I am going to use duct2d program to solve my duct. First get the geometry and generate the mesh for my duct. Then initialize the flow field of my duct. After that set the boundary conditions and display the geometry and mesh. If everything's all right, then call the solver to solve my duct. Once it is done, display the results of my duct. (6) At this level, it is very easy to understand. (7). As for those functions, we can write it in the same way as if we are writing Fortran code. Or you can replace it with your own functions if you decide to change it later on. Since we can include classes in the private data member, smaller packages can be created there to have private data member and the member functions, something like a purse. (8). In the above example, there is only one duct object created, namely myduct. we can easily create several ducts in one statement like, " duct2d my_entrance_duct , my_middle_duct, my_exit_duct ". Now we have a multi-block duct structure. (9). From this OOP point of view, it is easier to see the whole plan and it is also easier to write the code. (and if you decide to use someone's 2D solver, it can be easily included in the code if it is written in the same fashion. Then it is a plug-in code.)

There is (possibly was as I haven't seen it for a while) a programme available in the UK call Promula which converted Fortran to C. Try the Grey Matter site to see if its still available.