The point you made about Microsoft's monopoly was well taken. I think in the case of VB it turned out beneficial though. Being part of their Visual Studio package, I have seen a lot of "C stuff" migrate over to VB because the VB programmers wanted more power. I have even heard rumors that down the road VB would support OpenGL or a similar 3-D graphics language.

(1). As you know, the programming and 3-D graphics require some training and experience already. (2). The Numerical analysis and math modeling are many orders of magnitude more difficult than programming task. (3). This is the case since late 80's when more companies are interested in making quick money. And less companies are spending time and effort in doing right in CFD. (4). In 80's, the questions used to be "should we invest in doing CFD?". While in 2001, the questions are mostly "Which is the best code to do CFD?". In other words, there are more layers of new questions on the top of the old question. (5). So, to do CFD right, one has to stop thinking that a CFD code alone will give him the right solution. And I must say that, the current goal of the forum is to keep it alive first. As long as it is alive, there is always a chance to make improvement. (6). And the importance of using the language like c/C++(w/wo object-oriented programming) is to encourage self-study to expand the experience into other fields, so that one can stay alive before attempting to solve CFD problems. It is a very expensive hobby, rather than a money making field or trade. (7). But if you know how to use it and turn the products into a more competitive one, then it is a different story.

Very true!!!

The reason I have stayed with Fortran all these years is the inability of C/C++ to do run time allocatable arrays of higher dimension. I can easily do run time allocation of higher order arrays in PASCAL, and in JAVA and in FORTRAN but, so far, unless things have changed, I must write some fairly extensive code to do it in C/C++. One way is to write your code all in vector form with pointers to find the different components but this is error prone and unlike the mathematics used to do matrix analysis. I use VC for writing user interfaces to my FORTRAN code.

I don't like the use of the word inability. C++ IS able to do almost anything IF the programmer knows how to program it in. And then you just reuse the code and never worry about it again.

C++ is a lower level programming language and it gives the programmer more control. Although I was very much impressed with the OOL advances of f77 to F90.

I think that is what I said. The same can be said for assembly language, you can do anything you want, but I don't see many people advocating its usage. However, in the early 60's we did write application software for engineering problems using assembly language. Still, if productivity is of interest then one doesn't use it. It is very fast and 'once you have the routines written' etc, etc. I have FORTRAN code I wrote in the early 60's that will still compile with no errors on my F95 compiler. I have not had the same success with my C code. The C/C++ standard appears to be a moving target.

You guys are too concerned about which language to use ... My primary goal is to develop a well structured code (and this DOESN'T depend on the language you use) ... with a well structured code you can use with satisfaction any language you like even a JIT language ... Btw it is obvious that a vb programmer prefers Vb and that a C programmer likes C most !!!

How you are ABLE to structure the code IS dependent on which language you use. The higher level the language is the less code structuring you can do.

And yes a C programmer prefers C and a FORTRAN programmer prefers Fortran but what does a programmer that knows both C and FORTRAN prefer??? I think this was the original question.

(1). Well, if one is working alone, and the integration with other codes (being developed by other engineers or scientists) can be accomplished through file I/O, then he can just go ahead and write his code in his own way. (2). If he needs to turn in his code listings to his boss or other engineer for integration, then his boss or the program manager must make the decision right at the begining of the work. In this case, he will be forced to follow the decision if he still want the job. (3). Programming is tedious and bugs are common. So, the goal should be to focus on minimizing the error in the code. Fortran is easier than C/C++, so he should not be worrying about it at all.

1)I'm sorry but I don't agree with you ... during my whole career I've seen many times CFD experts writing code without a clear PP to follow. 2)Moreover structuring is by definition indipendent from the programming language (both ANSI and ISO standards ...). 3)Do you really think that with an OOL you can't structure a code ? 4)I was just provocating ... is obvious that the lower level language you use the faster your code will run (I hope no argue with this !!!) ... but what about time and cost of developing ? So if the topic of this discussion is which language is faster I'd say : machine language (is this affordable ???????????) ... but if we're concerned with the general efficency of a code (comprised the developing time) than it depends on too many factors and nothing can be said "a priori". Btw if you like only the speed this is a list of the code speed registered with a fixed code portion on a fixed platform (Pc) with different languages made in 2000 by ANSI (faster to slower): 1) Machine code; 2) Assembly; 3) Ansi C; 4) C++; 5) Fortran; 6) Visual C; 7) Visual Basic; To this list I say : "nothing new under the sun!!!!"

>>2)Moreover structuring is by definition indipendent >>from the programming language (both ANSI and ISO >>standard ) ---------------------------------------------------

You have a language. This language has rules. If you need to do something that breaks these rules than you cannot use this language. Therefore you must find a language that does not break the rules. In this case my experience is that c++ has less "rules" than fortran. Thus you are able to do more with it and have more options on how to structure it.

For example say you want to structure a code to make it the most easy for timmy to read. Timmy has a problem that his mind mixes the first two lines of code up, thus you want to do the following:

IMPLICIT NONE

PROGRAM Timmy_Tool

You cannot do this in Fortran. Well, I'm not quite too sure if you can do this in any language but it is a simple arguement that shows that structuring of a code DEPENDS on the language.

As a response to your standards... At the end, all languages have to produce something the computer can understand. Whats done in between is a whole different ball game.

I really cannot see any justification for your comment that structure is independent of language. Its simply not true. Possibly our ideas of "structure" are different.

Hi,

I agree with your ANSI list of fastest to slowest languages, mostly. But what is the difference of assembly versus machine code? In assembly, you use mnemonics instead of numbers to code processor instructions. The end result is the same.

If you have read the earlier thread, you may know that I program flow solver routines in assembly. Once you get the hang of it, you can put the same structure into your assembly routines as into any other code. The only difference: What takes 10 lines in Fortran or VB to program can take over 100 lines in assembly. Compactness of code, like 'structure', is critical in understanding and following it. Especially when you look at your code years down the road.

Axel Rohde

Here is a useful link on this topic: http://www.kai.com/publications/comp_phys/index.html

(1). Are we going to have the programming contest : "The fastest program only the machine can understand". (2). I would say that, (a). write the code in your own language first, maybe something like a flow chart.(b). write it in one of the programming language you are familiar with. (c). In the contest, translate it into assembly language. That's how the game programs are written, I think. (3). By the way, the assembly language is hardware specific, while Fortran and c/C++ are not. So, even if the assembly code is faster, it can only work on one type of machine. And most of the time, it will be useless, on other types of machine.

From the old-timer's corner again:

When access to the computer (main frame, housed in an air-conditioned 'temple' with its own complement of feeders, caretakers, and such) was expensive, the middle ground was often useful.

Most of the code in a CFD solver was devoted to I/O and setup, lots of lines of FORTRAN, not much of the CPU time. So the code was profiled to identify the time-sucking loops. These were usually a small fraction of all the lines of code. The compiler-generated assembly code for those few loops was examined carefully, then replaced with hand coded assembly instructions. Most of the code remained FORTRAN, but the inefficient assembly it generated ate only a small part of the machine's resources.

As an extreme example, I've seen the CPU required for a big CFD job (hours of CPU time) reduced by a factor of 5. For this example, perhaps 40 assembler instructions were replaced by 10. The readibility of the code was compromised not at all (the orginal FORTRAN in the replaced loop was commented so that its intent was preserved).

I suppose this could be done with C++ as well?

But, the catch is that memory and CPU time are relatively cheap now; it's the analyst who's so expensive.

I do agree with you ... if we just think at the economics of the sw development (in terms of costs and benefits) for a one shot sw. Suppose your company is developing a certain sw to solve a certain problem (this approach is true not only for CFD) ... optimizing the code will cost you 1000$ (just an example...) buying more RAM or a faster CPU will cost you 500$ (again an example ...) maybe it could seems that the second option is cheaper, but what if in the next year you want to implement some new features or modify something ? What if in this year the programmer team is changed and the previous team made no or poor analysis ? Answer : if you're lucky and your new working team is good enough they have to build back the analysis (some months of work ...)to proceed further, but you could be unlucky and your team has to rewrite the whole code from scratch ... So now what is cheaper ?