Martin Wegmann wrote:
just a short question, what's up with C ++ programming in GRASS. As far as I
remember, there does a module exist which is written in C++
r.terraflow.
but a few problems were encountered.
Yes. Some of them weren't strictly C++ issues, but general
non-portability issues (using gcc-specific flags in the Makefile) and
other non-standard behaviour (e.g. building separate short/float
versions of the object files from one set of source files).
Also, the configure/build systems needed some enhancements to better
support C++.
I suspect that it will still be problematic if your C and C++
compilers aren't both (the same version of) gcc. E.g. most of the
header and library tests in the configure script are done using
CC/CFLAGS; if you need different settings for C++, it isn't going to
work.
Is there any advice/recommendation to use C vs. C++ and which pitfall has to
be considered when using C++?
If at all possible, use C.
For C++, avoid anything which wasn't standardised before the ANSI/ISO
process got underway (e.g. exceptions, templates, and the standard
libraries). Compilers whose existing behaviour didn't match the
eventual standard have tended to stick with their existing behaviour
over the standard. Using such features may result in code which only
works on the C++ compiler which you use.
Also, excessive use of some features can result in unexpected
portability issues. E.g. extensive use of templates (particularly
generic libraries like STL) can result in function names which are too
long for the linker or for some binary formats.
Excessive use of many C++ features can result in code which is almost
impossible to debug (or even understand, if you aren't the author) due
to the rather convoluted relationship between specific sections of
source code and what actually ends up in the binary.
--
Glynn Clements <glynn@gclements.plus.com>