Hi AlanThe fixes are now committed. Hopefully this issue is all sorted and you
can undo the linkage changes you made to temporarily fix the building of the
examples.
Phil
From: phil rosenberg <philip_rosenb...@yahoo.com>
To: Andrew Ross <andrewr...@users.sourceforge.net>
Cc: PLplot development list <Plplot-devel@lists.sourceforge.net>
Sent: Monday, 27 October 2014, 11:30
Subject: Re: [Plplot-devel] Why is the set_stream() call commented
outforplstream::fill, etc.
Hi Andrew and AlanSo I believe I have fixed this issue now. I have put the
callback functions in a plcallback namespace, which I felt was the best way to
identify them for use as callback functions. I will update the docs and commit
the changes - although it would be good if one of you could check that the
docbook still builds fine as I don't have an easy way to check that on my
Windows PC (I will, when I get time make sure I have the requirements for
docbook builds on my Linux PC so I can test these in the future, albeit with a
bit of messing around copying stuff backwards and forwards)
However I had an odd obstacle when testing the fix. Initially I was getting
runtime issues with not finding the functions in the dll. Eventually with the
help of Dependency Walker I found that when running the examples from the build
tree, the dlls were being loaded from the install directory, so it was loading
an out of date library. If I removed the dll from the build directory then the
dll was not found at all. I'm not entirely sure how the libraries are loaded,
but I just wanted to check that this is the expected behaviour or whether the
libraries should be loaded from the build tree when run from the build tree?
Phil
From: Andrew Ross <andrewr...@users.sourceforge.net>
To: Phil Rosenberg <philip_rosenb...@yahoo.com>
Cc: PLplot development list <Plplot-devel@lists.sourceforge.net>
Sent: Thursday, 23 October 2014, 9:52
Subject: Re: [Plplot-devel] Why is the set_stream() call commented
outforplstream::fill, etc.
Well Phil,
If you feel strongly about it then go for c). As I said, it would mirror
what we do for callbacks for some of the other OO languages we support.
Andrew
On Wed, Oct 22, 2014 at 10:19:17AM +0100, Phil Rosenberg wrote:
> Okay, well, that works then. Although option c is probably only a couple of
> dozen lines of code.
>
> Actally having two plstream::fill methods might work as one will be const. I
> will test it and see. I'm not sure it is the "right" option. I probably feel
> the same about that as Andrew does about use the c function.
>
> Phil
>
> -----Original Message-----
> From: "Andrew Ross" <andrewr...@users.sourceforge.net>
> Sent: 22/10/2014 09:07
> To: "phil rosenberg" <philip_rosenb...@yahoo.com>
> Cc: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>; "PLplot development list"
> <Plplot-devel@lists.sourceforge.net>
> Subject: Re: [Plplot-devel] Why is the set_stream() call commented
> outforplstream::fill, etc.
>
> On Wed, Oct 22, 2014 at 07:40:34AM +0000, phil rosenberg wrote:
> > 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
>
> I agree with Phil that c) is probably the "correct" C++ way to do this, but I
> also agree it seems like overkill. This is the kind of thing I did for the
> Java classes, but there using the C API is not an option so it was more
> enforced, b) seems like unnecessary work without any real benefit. I could
> live with a) I guess despite my reservations. We have the C++ version for the
> direct calls, and just use the C version for the callback.
>
> Alan - if we went for my suggestion of have a static and non-static version
> they would need different names. I'm pretty sure you couldn't overload the
> function that way if both versions had exactly the same arguments.
>
> Andrew
> ------------------------------------------------------------------------------
> 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
------------------------------------------------------------------------------
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
