[GRASS5] Want GNU libavl ?

GRASS GRASS developer
1

Bjorn Roald wrote:

Wednesday, January 23, 2002 12:23 AM, David D Gray wrote:

I think ever more complex data structures get developed faster if you
use OOP techniques, but I'm not really advocating C++. I much prefer
java, Ada - a host of others - before C++. I do concede however that C++
is mainstream and many good implementations are available that are
difficult to find elsewhere, even in C, and we should adjust our policy
now to be more accomodating to these.

David,
I fully understand your wish for a more expressional language. Also, a lot
of functional and well designed code are available in many such languages.

I am not sure however, that I actually understand what you are proposing.
If I understand you correctly, you would like to use C++ in libraries that
later are linked into pure C executables. I think this is possible through
C interface functions, but I see it as less desirable, not very clean road .
I will expect that the convenience of using a C++ compiler for compiling all
the sources will soon be causing all the C/C++ sources to be built with the
C++ compiler. If that happens, then it is goodbye to plain old C in the
GRASS sources.

I don't think so. There is general resistance to using C++, and I believe that is generally a good thing. But many implementations of algorithms are written in C++, and these tend to be the ones the authors maintain as `production' quality. C implementations often are absent or poor in features, or are created just as an experiment that is poorly maintained

Neither will we se an abrupt change into good C++. In
general, I think C++ is a better fit in the higher level apps/libs than on
the lover level stuff of a mixed environment. These possible effects need
to be considered carefully.

To all,

I am just now reading this thread, a lot of good reasoning both for and
against loosening the policy. I have considerable C++ experience, in small
and large projects. I have also used and maintained a few C libraries as
part of larger projects developed in C++. My experience is consistent with
a lot of the balanced postings of C++ vs. C you can read on the net, but
frankly - most more or less religious C (or C++) advocates are noisy people
with little other than noise to bring into the debate. I think that this
get worse by 2 facts (among others):

1.
A lot of C programmers don't understand C++ at all. (still some of these
are noisy)

2.
A lot of C++ programmers don't know their C++ well. The language is to
complex to adapt to quickly without a framework limiting the scope of
knowledge needed for the more common programming tasks. This is a big
problem causing a lot of bad C++ code, which then back burns on the language
itself. This is not really fair.

Let us avoid falling into these holes when we debate. We need to keep in
mind that the worst thing that could come out of this is alienating some of
the contributing developers. Apart from that, I think it may be just as bad
to avoid making modern tools available to the developers due to policy
alone. Those policies need to be based on reasoning of what is best.

Agreed.

For my part, I rather maintain good C than bad C++.

Agreed again.

But for my overall
decision of whether to start working on the GRASS source code, an adoption
of C++ would most definitely count. Maybe there are other potential
developers thinking the same -- I don't know.

Well if you have an OOP outlook, and have from the start of your coding career, you perhaps can only really develop forward thinking in those terms. It's just that at the time C++ was the only tool most people had to develop with, and it was just accepted as many people just accept Microsoft and Windows because they don't know of anything else. When things started to open up in the mid-90's, and especially when Java came along, you could choose and critically evaluate OOP options. With OOP scripting languages like Python, PHP and Ruby now, that creates another avenue of choice, because these are really wrapper interfaces to an onject-oiented C environment. But still C++ has the widest circulation and is used more than any other OOP language, even among developers of free and open-source software.

We could talk about this for ever, but it can only be put to the test when a developer comes up with a specific proposal with genuine merit for including or writing a component in C++ (or other language).

David

2

David D Gray wrote:

We could talk about this for ever, but it can only be put to the test when a developer comes up with a specific proposal with genuine merit for including or writing a component in C++ (or other language).

Folks,

I hardly want to be a proponent of "C++ ification" of GRASS; however, I
would like to see the GRASS build system attempt to identify a C++ compiler
that can be used (normally just g++ of course) and to support building C++
modules.

For the time being I think we should avoid using C++ in libraries but I
think we should open up the option of some programs being in C++.

For r.in.gdal I have used a C "wrapper" api over GDAL which is internal
a bunch of C++ classes. However, OGR, my vector library, has no such
C wrapper and I am not terribly inclined to write one. However, I would
like to write a vector import and export capability based on OGR for
GRASS and that program would have to be in C++.

Therefore, I propose that for GRASS 5.1 we open up the option of some
GRASS programs (hopefully non-essential ones) be written in C++. Hopefully
from this we will get a better sense of what portability problems we will
encounter with C++. Then in GRASS 5.2 we can consider allowing some C++
code in the core libraries.

Even then, I would discourage attempts to rewrite large chunks of code to
be C++ friendly just for the sake of it. In past projects I have found this
can lead to corruption of what had been a clean C library.

Even if we allow C++, we might want to place some restrictions on it. For
instance, I avoid all use of RTTI, exceptions and templates in GDAL to avoid
portability problems.

Best regards,

--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent

3

I think that it is a decent proposition.

I recommand that we use the gidelines used by the wxWindows project:

http://wxwindows.org/standard.htm

wxWindows is a very large project compiled on many platforms with
differents C++ compilers.

I would like to make another proposal maybe for GRASS 6 : put in
libraries (which is already started) all computationnal stuff and
use Python as the glue logic (interfaces, user interaction, applications,
etc.). We will retain the avantages of shell scripts without all
the problems associated with shell scripts. Plus, we will gain an
free interpreter equivalent to MapBasic and the one used in ArcInfo.
With this, we open the possibility for users to write their own
applications. I invite those interested to look to wxPython, an
interface wxWindows to python and run the demo.

Frank Warmerdam wrote:

David D Gray wrote:
> We could talk about this for ever, but it can only be put to the test
> when a developer comes up with a specific proposal with genuine merit
> for including or writing a component in C++ (or other language).

Folks,

I hardly want to be a proponent of "C++ ification" of GRASS; however, I
would like to see the GRASS build system attempt to identify a C++ compiler
that can be used (normally just g++ of course) and to support building C++
modules.

For the time being I think we should avoid using C++ in libraries but I
think we should open up the option of some programs being in C++.

For r.in.gdal I have used a C "wrapper" api over GDAL which is internal
a bunch of C++ classes. However, OGR, my vector library, has no such
C wrapper and I am not terribly inclined to write one. However, I would
like to write a vector import and export capability based on OGR for
GRASS and that program would have to be in C++.

Therefore, I propose that for GRASS 5.1 we open up the option of some
GRASS programs (hopefully non-essential ones) be written in C++. Hopefully
from this we will get a better sense of what portability problems we will
encounter with C++. Then in GRASS 5.2 we can consider allowing some C++
code in the core libraries.

Even then, I would discourage attempts to rewrite large chunks of code to
be C++ friendly just for the sake of it. In past projects I have found this
can lead to corruption of what had been a clean C library.

Even if we allow C++, we might want to place some restrictions on it. For
instance, I avoid all use of RTTI, exceptions and templates in GDAL to avoid
portability problems.

Best regards,

--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

--
Robert Lagacé, professeur
Pavillon Comtois
Université Laval
Ste-Foy, Québec, G1K 7P4
tel : (418)-656-2131#2276
Fax : (418)-656-3723
E-mail : lagace@grr.ulaval.ca

4

Frank Warmerdam wrote:
> David D Gray wrote:
> > We could talk about this for ever, but it can only be put to the test
> > when a developer comes up with a specific proposal with genuine merit
> > for including or writing a component in C++ (or other language).

> I hardly want to be a proponent of "C++ ification" of GRASS; however, I
> would like to see the GRASS build system attempt to identify a C++ compiler
> that can be used (normally just g++ of course) and to support building C++
> modules.

To identify a c++ compiler is fine in the build system is fine.

> For the time being I think we should avoid using C++ in libraries but I
> think we should open up the option of some programs being in C++.

This is reasonable as long as we point people to the problems of C++.
GRASS is Free Software we will not stop people from using it from C++.

> Therefore, I propose that for GRASS 5.1 we open up the option of some
> GRASS programs (hopefully non-essential ones) be written in C++.

We should make it a requirement that they are non-essential.

> Hopefully
> from this we will get a better sense of what portability problems we will
> encounter with C++. Then in GRASS 5.2 we can consider allowing some C++
> code in the core libraries.

Sounds like a plan.

5

On Thu, Jan 24, 2002 at 01:36:52PM -0500, Robert Lagacé wrote:

I would like to make another proposal maybe for GRASS 6 : put in
libraries (which is already started) all computationnal stuff and
use Python as the glue logic (interfaces, user interaction, applications,
etc.). We will retain the avantages of shell scripts without all
the problems associated with shell scripts. Plus, we will gain an
free interpreter equivalent to MapBasic and the one used in ArcInfo.
With this, we open the possibility for users to write their own
applications. I invite those interested to look to wxPython, an
interface wxWindows to python and run the demo.

As a known friend of python I of course sympathize with the suggestion.
However GRASS 6 is far away and we have many task to solve.
We cannot decide on radical long term plans.

GRASS is a huge project and we need to be conservative.
It carries a history and stories from users.
C will be GRASS' main language for quite some time to come.
I recommend to keep it this way for the core of GRASS
for the foreseeable future.

But we have to keep this in mind: GRASS is Free Software.
We won't stop anybody from doing any experiments they want.
Regarding GRASS this will be experimental add-ons.
Why not reimplementing a Free Software GIS in python,
based on GRASS libraries?
The packages on freegis.org show that there is much energy
and room for experiments.

If a person asks what can be done for GRASS,
there are many task to solve first. A lot have to do with code-cleanup.
We need to get this done first.

6

Frank Warmerdam wrote:

> We could talk about this for ever, but it can only be put to the test
> when a developer comes up with a specific proposal with genuine merit
> for including or writing a component in C++ (or other language).

I hardly want to be a proponent of "C++ ification" of GRASS; however, I
would like to see the GRASS build system attempt to identify a C++ compiler
that can be used (normally just g++ of course) and to support building C++
modules.

For the time being I think we should avoid using C++ in libraries but I
think we should open up the option of some programs being in C++.

For r.in.gdal I have used a C "wrapper" api over GDAL which is internal
a bunch of C++ classes.

That makes the library available to programs written in C, but it
still suffers from the problem that any precompiled libgdal will only
work on systems which have exactly the right version of libstdc++
(using the same version of libc, built with the same major compiler
version).

The net result is that a user who obtains a binary distribution won't
get a working version of r.in.gdal. They would need to independently
obtain a version of libgdal which was built for their specific
platform, or build it themself from source.

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.

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

7

Friday, January 25, 2002 5:23 AM, Glynn Clements 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?

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

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

Without a good solution to this I tend to agree with Glynn -- well rewriting
things may sound rather extreme.

Bjorn

8

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@virgin.net>

9

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

10

To Grass5 list, slightly off the topic but pertinent
to the compiler topic...

I just built the gcc-3.03 using the commands

"./configure --prefix=/cygnus/usr --enable-threads=win32"
  "make bootstrap-lean"

See the URL http://www.gnu.ai.mit.edu/software/gcc/ for info

See the following links for new features for gcc, g++, and g77
http://www.gnu.ai.mit.edu/software/gcc/gcc-3.0/features.html
http://gcc.gnu.org/onlinedocs/g77_news.html

Get the core, g++, and g77. The complete one has java and objc
as well. If you get the objc there is a conflict in one
of the include files for a BOOLEAN definition. It is a
configure issue. You will have to hand tweak that one.

John Huddleston, P.E.

-----Original Message-----
From: grass5-admin@grass.itc.it [mailto:grass5-admin@grass.itc.it]On
Behalf Of Bjorn Roald
Sent: Sunday, January 27, 2002 2:23 AM
To: Glynn Clements; Bjorn Roald
Cc: warmerdam@pobox.com; grass5 developers list
Subject: RE: [GRASS5] Want GNU libavl ?

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

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5