Re: How to start learning.
On Dec 24, 6:55 am, Jeff Schwab <j...@schwabcenter.com> wrote:
James Kanze wrote:
On Dec 22, 6:09 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
Matthias Buelow wrote:
Bo Persson wrote:
Just if you want to publish the interface to other
languages. A C interface is the least common denominator,
which almost anyone can adapt to.
Which exposes the biggest problem with C++ -- it exposes
an interface noone can reliably talk to, not even other
C++ code compiled by a different compiler.
This is a popular, but unfounded, accusation. C++ is
portable at the source level, just not at the compiled,
binary level.
In practice, it's not even totally portable at the source
level. Of course, C++ isn't the only language to have that
problem either. In a certain sense, you unavoidably have it
as soon as there are two different code bases for the
compiler; compilers have bugs, and two different code bases
will have different bugs. In the case of C++, we also have
the question of how well they implement the standard, with
code which compiled with g++ 3.x failing to compile with
4.x, etc.
There is a large, common subset.
Certainly. There's even a large common subset with CFront 2.1
or Zortech 1.x---I have some code originally written for the old
Zortech which still compiles today.
The problem is knowing the limits of that subset in advance, for
all of the compilers you have to target now, and may have to
target in the future. With a reasonable degree of accuracy; you
can't possibly get it perfect, because you can't know in advance
what errors might be present in some future version.
Incidentally, I wrote some code last week that compiled and
worked as expected with one GCC 3.x, but not with a later 3.x.
The issue was that I moved a template definition up in its
translation unit, before the declaration of one of the
non-dependent names in the definition. The older GCC 3 failed
to notice that the name was not yet in scope when the template
was defined, but found the intended name when the template was
instantiated. I wonder how much processing of template
definitions the various compilers actually do.
Variations in the lookup of non-dependent names are probably the
biggest portability problem today. Curiously enough,
portability seems work best using the reverse of normal
procedure: code which compiles and works with the most recent
compiler will usually work with older versions. (Usually, it's
the opposite: code which compiles and works with older compilers
continues to work, but the fact that some code compiles and
works with a newer version doesn't mean it will do so with an
older one.)
[...]
In fact, I'm having trouble bringing to mind any language
other than C with the kind of binary compatibility you're
suggesting.
Fortran IV:-). Assembler.
Assembler varies wildly from one assembler to the next. (I
don't know Fortran, so no comment.)
Assembler varies from one machine to the next, but I've rarely
encountered problems with upgrading the version of the assembler
for the same machine.
1. Some implementations, e.g. GCC, do define versioned ABIs.
2. Even Java's byte-code is not forward compatible among JVM
versions.
You mean backward compatible, don't you? A modern JVM should
execute the older .class files.
Yes, thank you for the correction.
Of course, even the underlying hardware has such problems:
Sparc added some instructions with v9, and if your code uses
them, it won't run on older processors. (The difference is,
of course, that we were promessed that this would never
happen with the JVM.)
Even more insidious are instructions that still "work," but
very slowly.
That's one advantage JIT compilers have; they know the exact
machine they're running on, and can tune for it.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34