(1). Well I remember seeing statements that Windows GUI in MS Windows are not real class and object as is defined in C++.(although there is a window class in MS windows) (2). VB also can not do the real class and object. (3). Delphi's GUI also is not real class and object as in C++. (3). So, be careful, when you are dealing with these different languages and GUI. Somehow they are not the same thing.

If we consider to this discussion, Can we conclude that C++ or MS Visual C++ has a good software to conduct OOP or GUI programming especially for CFD or other engineering programming ?

(1). I think you can make such conclusion. (2). Data base, computer graphics, games programming, are all written in C++ now. For PC windows application, VC++ is the standard. (although there are other C++ packages available) (3).Whether to use VC++ in OOP style or not, it is purely a decision of the programmer.(In VC++, you can also write the code in DOS style) But the tools are there. The current main stream is OOP and VC++. (it maybe easier to use VB or Delphi, but each has its own limitations) (4). So, for a cfd engineer, it is a good idea to know C++, in addition to Fortran, such as f77 (Basic is almost like Fortran) in order to make life easier to interact with the main stream programming field. (5). I would say, to survive in the future, one must learn C++, in addition to Fortran. You will be completely lost, if you don't have any knowledge in C++. (In old days, computer graphics codes were written in Fortran.) (6). It is very hard to find a book on Fortran in a book store nowadays. You see only C++, VB,VC++ and Java books.

From this discussion, wether we make a conclusion that for development of the CFD source code or other engineering programming, we must know and use F90 and C++ or VC++.

In other word, the combination of the F90 and C++/VC++ with IMSL routine is a good idea to get the OOP in CFD development beside of the using of programm package such us Fluent etc.

As a engineer, we have to know about C++ & F90.

I happened to glance at the ongoing discussion about OOP for CFD codes. Principally only two persons have argued about the merits and demerits. Actually andy has very clearly summarised the merits and demerits in his first (or second) message stating that the OOP is not much of a help if you are primarily concerned about the speed and you know what you are doing and your code is "not too big."

However, CFD codes are not necessarily small and there is indeed a lot of book keeping that goes on. After all, a primary aim of CFD should be to solve some problem. More so an applied problem. No longer can we say that we have a top of the line CFD code that solves a two-d problem. Problems that are being solved using CFD are getting to be necessarily three-d in nature.

Once certain algorithms have been tested on baby problems, then it is the CFD which should set about application of the same for more complex problems. (I can only relate to aerospace application since that happens to be my area of application.) Then, the code development derives great benefit from OOP modelling. It is indeed much easier to set skeletal program and keep adding stuff without having to touch too much of code. Clearly, speed cannot be matched. But, codes do tend to be highly modular and you can use the OOP concepts to build in additional safety features.

C++ together with its STL support serves as a great tool. Algorithmic oriented issues can be approached using the concepts laid out in STL. It allows one to think of flow field rather than an array of numbers.

Fortran 90 could be a good alternative. It would be generally possible to implement a code designed using OOP concepts. But a Fortran 90 code does not tend to be as clean as a C++ code to read. Perhaps this is purely a personal observation.

While working with C++, I find that I could not possibly return to Fortran environment. I would have to sit and work out many more details before writing any piece of code at all (as opposed to writing code in C++ using OOP approach).

Better C++ compilers can only be expected if there are more codes written in C++ among CFD practitioners. If Fortran 90 finds a need to mimic OOP like features in its implementation, then it is a clear indication of the superiority of the methodology for writing clean, robust, complex codes.

Although OOP programming may help in the construction of modular codes for the development of large applications, I believe that the use of OOP for programming large scale codes is unnecessarily complicated by the compilers built on machines which do not match up to the performance of FORTRAN compilers which also have a universal appeal.

The machines now carry f90 and ANSI standard libraries which improve code clarity and portability.

I am skeptical about the an extensive library dependent environment in OOP and multi-platform portability of large CFD codes.

Ravi

hi,

you appear to contradict yourself in your opening remarks saying that "Although OOP programming may help in the construction of modular codes for the development of large applications, I believe that the use of OOP for programming large scale codes is unnecessarily complicated ..."

a large program is a complex program. oop approach helps to implement such programs more successfully than using languages that do not support oop (such as fortran).

besides, your comments that "code is unncessarily complicated by the compiler built on machines which do not match up to the performance of fortran compilers" is not clear either. compiler neither complicate a code nor do they simplify. compilers simply compile! the language issue has nothing to do with compilers capability.

it is worthwhile to take a look at the following web page regarding the compiler performance issues: http://www.kai.com/publications/comp_phys/_index.html this page clearly echoes my belief that c++ compilers will get faster by the day and since it is much simpler to think in terms of oop and implement them in c++, more codes are likely to emerge that use oop. currently it is true that scientific codes tend to be slower. but if you weigh the benefit of ease of program development using the incremental design, much like the research that we do in any discipline, programming in fortran tends to be much less attractive.

you say that "The machines now carry f90 and ANSI standard libraries which improve code clarity and portability." in fortran, there is no standard library. all the functionality that comes with it is part of the language itself. i certainly cannot understand as to how this could improve code clarity. fortran 90 borrows much of the ideas from c++ (and other languages that support oop, i suppose). this is because no longer the least-cpu-time code is considered a beauty.

there is no need to be skeptical about the library dependent environment in oop. this is only true of java. but then java is not quite the language for large and complex projects. the libraries that come with c++ are a well defined standard.

-vidyadhar mudkavi

october 20, 2000