Re: [Plplot-devel] State of the Union

[Geoffrey F. <fu...@ga...>]

Alan W. Irwin writes:
 > I have a question about one area that caught my eye.  I would like to know
 > the effort required to convert the core of PLplot to C++.  How much
 > full-time would it take for *you* to sit down and re-write the whole core of
 > PLplot (excluding drivers) in C++?  Is this a project that would take say a
 > week of your vacation time or would this require several months full time
 > before you got something that was beginning to be useful.

Mmm, well, to "re-write PLplot in C++" sounds like a big job.  The way
I would advocate starting, is to simply "compile PLplot with C++".  If
we were to approach this by say, renaming all (or most, see below) C
files from xxx.c to xxx.cc, and then twiggling whatever makefile stuff
was needed to compile with C++, and fixiing whatever minor syntax
issues there might be, I would expect we could be "compiling with C++"
with a time investment of a few hours or so.  Once the C is actually
being regarded as C++ by the compiler, the human programmers can start
writing new code in C++ at will, on timescales that relate to their
personal inclinations and time budgets.

 > My C++ skills are non-existent, but if you say there are lots of
 > benefits to moving to a C++ core, I believe you and would be
 > willing to learn it.

I don't do my main coding activities in anything else.  

 > Certainly, the KDE team absolutely swear by C++ as a way to get newbie
 > programmers quickly writing code.  Although the KDE experience with a
 > massive C++ project has exposed some Linux C++ weaknesses, my impression is
 > those are rapidly becoming solved. For example, apparently some of the long
 > start up times for KDE apps are due to a Linux binutils problem with C++
 > that is about to be fixed.

Well, not really "Linux C++ weaknesses", I suppose, but more like "GCC
C++ weaknesses".  All GCC versions prior to 3.0 are essentially
unusable from a C++ perspective, as far as I'm concerned.  Sure, lots
of stuff works in 2.95.3, but too many things don't work, too many
things that are perfectly legal C++ won't compile with gcc 2.95.3,
that I simply haven't been able to use it.  That's why PLplot's C++
autoconf autodetects KCC, for example.

With GCC 3.0, I think GCC's C++ support is finally good enough to take
seriously.  I think if we coded in C++ in PLplot now, people would be
able to still use the result, provided they compile with GCC 3.0.
BTW, this doesn't mean I don't know of serious bugs in 3.0--I do--but
the number of them is at least low enough that it isn't such a painful
experience like it used to be.

I don't know when major Linux distros will convert to 3.0.x strain
versions of GCC.  Hopefully soon.  But there were many ABI changes
going from 2.95.x to 3.0.x, so we're talking about a total recompile
here.  Probably will take the distros awhile to brace themselves for
the effort.

 > I am concerned about the change to a C++ core from the point of
 > view of the various front ends.  How would that work?  If no direct
 > extension of a front-end was available for C++ (e.g., the yplot
 > yorick front end) would you provide C wrappers for your C++ core?

I would view it that retaining a C callable interface was a mandate.
Fortunately this is trivially easy to achieve.  C++ allows you to
declare functions with C linkage (no mangling would be introduced,
etc), so you can retain C API entry points, which then call C++ code
inside. 

I could imagine that the C PLStream becomes an opaque handle.  mksstrm
just chooses which active stream to use--ie, sets the active (global)
stream pointer for the C api--then all PLplot C api functions become

extern "C" 
void plXYZ(args) { return pls->XYZ(args); }

Then the whole core would just work directly on a real C++ stream
/class/ object (instead of on plsc, the global single active PLplot
current stream pointer).

In other words, in summary, no externally visible change to the API.
No impact on front ends.

But the coding beneath the C-callable layer could be done in C++, make
use of the better features C++ provides for programming in the large,
etc.  We could finally have a precision-neutral C++ PLplot library
because the C++ interface could be templated, etc.

That's just a very rough outline, it would have to be sketeched out in
a lot more detail before I would think there would be a real chance of
turning this sales pitch into a closed deal.

 > I did notice that my favorite front end, python, discusses C and
 > C++ extensions simultaneously so I don't think there would be a
 > problem for that front end.

I dunno if you know, but I am/was the Python C++ Sig chair.  The
python C++ sig never really delivered, and I think Guido has "reaped"
it by now.  But I "happen to know" that it is possible to make Python
extension programming a /lot/ easier by using C++.  It's one of the
reaons I haven't worked on plmodule.c actually, because knowing how
much nicer it is possible to make Python extension programming in C++
than in C, has totally disenthused me about working on a major C
extension module.

It's a big topic, too much to get into here probably.  The Python C++
sig failed to deliver for a variety of reasons.  But if PLplot were in
C++, then plmodule.cc could at least use good C++ techniques for
interacting with Python, independent of whether Python ever grows a
quality C++ interface.

-- 
Geoffrey Furnish         fu...@ga...