Hi Andrew and AlanI still think that a public plstream::plfill function is bad
C++ style. One af the big ideas in C++ is data hiding and doing this exposes a
method that we never want a user to call. I personally don't see any problem
with using C-Style functions in C++ - for example the only way that is
permitted to extend usage of std containers is with C-style function as you are
not permitted to inherit from them.
So in my opinion these are the options that are good C++ style
a) Just use the C plfill option - but obviously Andrew doesn't like this and I
do see why.b) Create a C-Style function in the C++ header with a slightly
different name - perhaps in a namespace to avoid clashes which calls plfill.
This is only really a very thin wrapper, but it does distinguish the C++ API
from the C APIc) If we want to go to town an do it in an object oriented way
then here is the method I would propose: We create a plfiller class which
accepts a function pointer in its constructor. This has a private method
getfillfunction() and declares plstream as a friend. Instead of passing a
function pointer to plshade, we pass a plfiller. We also declare a public const
static plfiller in plstream called defaultfiller or something which uses
plfill.Now the user can do a number of things. They can call plstream::shade
with plstream::defaultfiller, they can call it with plfill, which will
implicitly construct a plfiller, they can call it with their own function
pointer which will again implicitly create a filler object or they can create
their own plfiller which will return a different function pointer of their own
design.
Option c is rather more complicated than the other 2, but is ensures all the
data hiding requiresments of good C++ style and to me is the much better option
style wise than just having a static plstream::plfill method.
Phil
From: Alan W. Irwin <ir...@beluga.phys.uvic.ca>
To: Andrew Ross <andrewr...@users.sourceforge.net>
Cc: Phil Rosenberg <philip_rosenb...@yahoo.com>; PLplot development list
<Plplot-devel@lists.sourceforge.net>
Sent: Wednesday, 22 October 2014, 0:32
Subject: Re: [Plplot-devel] Why is the set_stream() call commented out
forplstream::fill, etc.
On 2014-10-21 22:58+0100 Andrew Ross wrote:
> My other option was to provide a static version of plfill for use as a
> callback function (without the set_stream call) and a non-static version
> with the call to set_stream for use elsewhere. This would make the two
> different usages clear.
Let's agree we don't want to do violence to both the plshade and
plshades API. That only leaves some variant of Phil's option 1 such
as use C callbacks (i.e., plfill, pltr0, pltr1, pltr2) for all C++
callbacks or the option you expressed above which would imply leaving
plstream::tr[0-2] defined and used as C++ callbacks just like they are
now and implementing the static form of the C++ callback that wraps
the C plfill identically to the way tr[0-2] are handled (no set_stream
call).
Assuming Phil is willing to go along with the above suggestion, then
the other question I have about the above option is whether or not it
is necessary for the static and non-static forms of fill to have
distinct names. (I thought so when I proposed something very similar
to the above, but I am not so sure now since you didn't mention it).
If no separate name is needed (i.e., C++ recognizes that pls->fill in
our examples refers to the non-static form with set_stream that is
needed for direct calls and plstream::fill refers to the static form
without set_stream required for callbacks), then we are very close to
a correct solution now.
Here are the results of some relevant searches in our example source
code:
software@raven> grep 'plstream::fill' examples/c++/*
examples/c++/x15.cc: plstream::fill, true, NULL, NULL );
examples/c++/x15.cc: plstream::fill, true, NULL, NULL );
examples/c++/x16.cc: plstream::fill, true, NULL, NULL );
examples/c++/x16.cc: plstream::fill, true, plstream::tr1, (void *)
&cgrid1 );
examples/c++/x16.cc: plstream::fill, false, plstream::tr2, (void *)
&cgrid2 );
examples/c++/x16.cc: plstream::fill, false, plstream::tr2, (void *)
&cgrid2 );
examples/c++/x16.cc: plstream::fill, false, plstream::tr2, (void *)
&cgrid2 );
examples/c++/x16.cc: plstream::fill, false, plstream::tr2, (void *)
&cgrid2 );
examples/c++/x22.cc: clev, nc, 0, 1, 1.0, plstream::fill, 0, NULL, NULL
);
software@raven> grep 'pls->fill' examples/c++/* |grep -v fill3
examples/c++/x12.cc: pls->fill( 4, x, y );
examples/c++/x13.cc: pls->fill( j, x, y );
examples/c++/x21.cc: clev, nl, 1.0, 0, 1.0, pls->fill, true,
NULL, NULL );
examples/c++/x24.cc: pls->fill( 4, px, py );
examples/c++/x25.cc: pls->fill( npts, x0, y0 );
examples/c++/x27.cc: pls->fill( 1 + steps * windings, xcoord, ycoord );
examples/c++/x30.cc: pls->fill( 4, px, py );
examples/c++/x30.cc: pls->fill( 4, px, py );
So it appears from these searchs that plstream::fill always refers to
the callback, and once pls->fill is replaced by plstream::fill in
example 21, all references to pls->fill will refer to direct use.
So with that example 21 change and implementation of the static and
non-static versions, we would have a complete solution which I could
commit in ~15 minutes or so. However, if a separate name is needed
for the callback version, then a bit more editing would be required of
the examples.
So if Phil is willing to go along with C++ callbacks and assuming one
of you answers my question about whether separate names for the two
cases would be required, I would be happy to implement the actual
minimal commit just to finish off this topic (if one of you doesn't
beat me to it).
Alan
__________________________
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________
Linux-powered Science
__________________________
------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
