gn said:
Earl Purple schrieb:
Well - The problem here is that there is one java against many different C++ compilers.
Java 5 has some significant changes in it.
Normally one should think that if you are
programming C++ conform to the standard (and of course capsulating (I
still don't know the right word here in english) system functions) your
programs should compile at every platform where you have a C++
compiler. In reality thats not the case because many compilers are not
conform with the standard, especially concerning templates.
Well we are dealing with 3 situations:
- Open-source libraries. They need to build in your compiler but once
you've built it you can link it with your code easily. I much prefer
using open-source libraries. The only issue is when they're written in
macros because of all the different compilers they might be dealing
with, and particularly if they require you to set some define just to
have it compile standard C++. The situation should be that those who do
not have standard-complliant compilers should be the ones who have to
define something.
- Pre-built libraries. Now you have to get the binaries from the
vendor, and usually there are a certain number of header files but they
are basic enough to work for any compiler. The clash now comes with
linking against run-time libraries.
- Hybrids which could have the worst of both worlds, i.e. you need
compiler-specific defines and have to build with the correct runtime
library. Visibroker is the actual one I had problems with.
Additionally people who are using things like visual C++ or Borland C++
Builder are often not aware of using non standard libraries. You are
also right with the different GNU versions where I had some problems
with my template syntax.
It is incredible how many are still using VC6. Problem is of course, a
lot of their code would break on VC7/8 because it's full of "wrong" C++
that VC6 would compile.
The same is true for any modern C++ compiler, although GNU usually
allows specific switches for backward compatibility.
But all this is not a problem of C++, but of the compiler developers
(let's see what the next standard brings and how fast they are in
implementing it to all compilers). There are also many other things
that I am missing in current compilers (e.g. return value optimization
for recursive functions). I really think that C++ will become much
faster in the future because there are many such things to optimize
that is to complicated for todays compilers.
Runtime performance is not the main issue. Java has improved in that it
has improved its runtime performance to be adequate enough. Whether it
matches C++ is not always relevant, as long as it is adequate for the
task in hand. (In some cases Java can match C++ perfectly well or even
out-perform it).
The big issue here seems to be portability. C++ badly lacks a standard
runtime library in the way C has one, and a standard demangler so that
you can link GNU libraries with VC8 or Solaris ones on their specific
platforms without requiring a "C" interface.
In addition, I still feel that the reluctance of C++ to have a standard
for a network, threads, file-system, graphics device etc is something
serious lacking as part of its portability, even if there are 3rd party
libraries for many of these things, even open-source ones.
In the end everything depends on the specific tasks. For my field of
work (computational chemistry) it's simply no question to use anythingh
else than C++ or Fortran, because those quantum chemical calculations
are still to slow even on huge clusters and even for small molecules. I
also think for bigger projects in the software companies it should be
no problem to have C++ and java programmers working on the same
project. It's no problem if you have a good design.
For this there is always JNI which allows Java to interact with C. The
"D" programming language can also interact with C libraries. Once again
C++ is left out of the equation.
