[GRASS5] Want GNU libavl ?

[Bjorn Roald]

Glynn Clements wrote:
> 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.

Agree that these may be problems, but a lot less so if you are working on
well designed and well coded systems.  Just like in C, the C++ language
allows a lot of potentially evil constructs.  Used with caution and only
when you really need them, they are mostly handy tools though.  My main
preference of C++ over C comes from its ability to express good, clean, real
world functioning software with a preferred subset of the language, and at
the same time avoid using these potentially evil constructs.  I don't think
anyone can claim that for C.  I am not proclaiming that this comes natural
to all that attempt to code in the C++ language.  That fact is a major
problem for the C++ language.  I guess it could be stated that this is an
educational problem, or alternatively some will say that the language is
evil --- meaning you should use something "better"(Java/C#/Phyton...).  I
vote for better education.


A few direct remarks on what you are writing:

Some of your statements are remarks that apply to all OO languages, and have
no unique bearing on C++.  Most people with experience from OO languages
find themselves searching the class hierarchy from time to time, but few (if
any) will disagree that well designed base classes (or interfaces) are a
blessing for the programmer.  Good documentation (which often are generated
from sources) make this less of a problem.  Also, good but often simple
tools makes searching simple and fast.

Operator overloading are a potential evil, but that is in the hands of
people asking for it.  This is a fact with normal functions as well.  If you
have a function in C called makeCheese(); you would expect it to make
cheese, not eat it.  There is no difference with operator overloading in
C++, the operators have specific semantic meaning in the base language, and
this semantic meaning should never be abused.

I can not see how you can state that copy constructors hide function calls.
Do you have an example?

Pure type converting operators (created by overloading operator=())are
almost always evil.  I also count constructors with one parameter that are
not declared explicit for type convertion operators, they are evil unless
the convertion they perform is clearly intuitive, reasonable and without
dangerous hidden pitfalls. Such an acceptable convertion is the convertion
from char* to std::string which is allowed through the constructor
std::string(const char*);  The opposite direction is not supported by an
automatic convertion since the designers of the standard library decided not
to make an convertion operator for this.

> 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++.

Agree, although I personally don't see this as a major drawback.  All you
really need is to accept to use a C++ compiler (and other tools), and accept
the fact that your code are C++ infected C code.  The C++ compiler will eat
it, and all C++ libraries in your "former" C code.  This ability of the C++
language to take over C code, are in my opinion the most contributing factor
to the success of C++ in the commercial world.  I accept that some select to
keep a clean road, with an old language, rather than perform this kind merge
of entire projects into a more feature rich language.  I am just pointing
out that this is possible road ahead.

>
> 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).

This is true, but mostly history these days.  I am confident this will
shortly become false.  I myself test some of my C++ standard code on g++
under Linux and windows, Visual C++ under windows, and SUN SparcWorks/Forte
on spark boxes at work.  Problems are fading away as new versions of the
compilers are released, and I hardly ever have problems compiling and
running the programs with identical results.

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

agree

>
> 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).

This is meaning that any C++ based library in principle could be acceptable
to use in GRASS, provided the needed functionality are wrapped in a C
interface and the binary compatibility issues are solved in acceptable
manner.

>
> > 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.

Jepp, its quite simple, and basically everybody has benefited from that.

>
> > 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.

I guess we should all agree that the only thing that counts, is what
actually work.  In such regards we should lift our heads and look around for
success stories.  In the free software world KDE comes into mind as
something successfully using C++.  They actually do binary distributions on
multiple platforms as well, and at least users seem to be happy.

>
> 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.

agree

I think in the end we will not agree on all of this.  It is also possible
that the best path for GRASS is to continue using standard C, an avoid
infesting its sources with C++.  For my part, if I ever get started on some
of my more ambitious ideas, it will not be as part of the GRASS source tree.
I think it will be part of some other C++ project, or I start a new.  This
will not exclude the possibility of the projects benefiting from each other,
hopefully.

Bjorn