[GRASS5] Want GNU libavl ?

[Glynn Clements]

Bjorn_Roald wrote:

> > As you can probably guess, I'm personally against any use of C++ in
> > either libraries or programs; even to the extent that I would view
> > re-writing libgdal in C as a worthwhile use of developer time.
> >
> 
> Is this due to the binary compatibility problem with g++, or are there also
> other issues?

My general dislike of C++ isn't just due to binary compatibility. My
main complaints with C++ are:

1. Legibility.

It's harder to understand C++ code without understanding the overall
structure of the class hierarchy. Function calls can be hidden by
operator overloading, copy constructors, and type converters. Even
once you've determined that a function call is occurring, figuring out
exactly *which* function is being called involves determining which
parent class is providing the implementation, and which variant
actually matches.

2. Non-availability to C code.

If a library is written in C++, wrappers are required if it is to be
callable from C. The existence of C++ libraries imposes a pressure to
write applications in C++.

3. Portability.

Apart from the binary issues, you need to take account of the fact
that C++ is less portable than C at the source code level also. I
would suspect that GRASS could be particularly prone to this problem,
as there seem to be so few developers using anything other than
Linux/x86, while end users will probably have a fairly wide range of
hardware (I would expect academic institutions to consitute a large
proportion of the GRASS user base).

Also, bear in mind that you don't just need a compiler. Debuggers,
code analysers and the like are also important.

As for the specific case of libgdal, it's really only the binary
compatibility issue. The library has already been written (so
legibility isn't really an issue), and it includes C wrappers (and so
it's available to C code).

> What I am trying to get to is: If the binary compatibility problem has a
> solution we can live with, is it then conceivable that you will change your
> mind about accepting use of C++?

As outlined above, I have other objections. #3 will reduce with time,
but #1 and #2 won't.

> I generally agree that binary compatibility is a problem that need to be
> addressed seriously, but I do not think this problem is general for the
> language.  I have never heard of such a beast in the windows world, where
> C++ infected DLLs float freely between compiler versions and vendors.

Under Windows, then ABI is completely dictated by Microsoft. Either
your compiler/library/whatever is compatible with Microsoft's, or it's
broken.

> Even
> name mangling is a manageable problem that can be standardized or automated
> by compilers and loaders.  My guess is that this problem is in part due to
> whinges in the header files of the standard libraries between versions of
> libstdc++

It's certainly *possible* to solve the compatibility issues. However,
it's much harder for C++ than C, and it hasn't been achieved for C++
to the extent which it has for C.

To a large extent, the binary compatibility issue is *the* main reason
for C's popularity. Writing libraries in C is trivial, using them from
other C programs is equally trivial. Mixing C and assembler is almost
as easy, as is mixing C with Fortran and C++. In fact, C++ basically
owes its existence to the fact that Smalltalk was too far removed from
C.

-- 
Glynn Clements <glynn.clements at virgin.net>