On Thu, Oct 16, 2014 at 04:34:53PM -0700, Alan Irwin wrote: > On 2014-10-16 20:39+0100 Andrew Ross wrote: > > > > > Alan, > > > > It's because these three functions are callback functions which are > > called from another plplot function. They do not operate directly on > > a stream. > > Hi Andrew: > > I may be misinterpreting what you are saying above, but I noticed many > direct as well as more limited callback uses of these three functions > in our examples, see below. > > > > > The C++ class maintains a stream variable for each instance of the > > PLStream class. This means you can have multiple streams (i.e. windows > > / files) and not have to worry which one plplot is currently using. > > It's all hidden in the object orientation by calling set_stream > > each time a plplot API function is called for a particular object. > > > > The callback functions don't need to do this since they are being > > called from another plplot function. If you look in plstream.h > > you will see these functions are marked static which means there > > is a single copy of the function shared across all instances which > > does not have access to the local variables in the class. This > > means that calling set_stream wouldn't actually work anyway, > > enforcing this distinction. Uncommenting would generate a compiler > > error. > > You lost me a bit because of my lack of knowledge concerning C++. > Nevertheless, let me ask a supplementary question. Your explanation > indicates these are specially treated because they are callback > functions, but that is not the full story. For example, those > functions are used directly and not as callbacks in many examples; if > you look for "fill" in the C++ examples, there are many references to > pls->fill rather than plstream::fill. I checked a number of those, > and the pls->fill ones are mostly direct although in example 21 it > appears that the pls->fill form may also be used as a callback. I > have no idea whether that example 21 difference in pattern matters, > but I do wonder whether if one of our users attempted to use fill, > fill3, or gradient directly in a multistream application similar to > example 14, would they run into an error because of the lack of > set_plstream call in the C++ binding? Note our current set of > examples does not test this case because fill, fill3, and gradient are > all missing from example 14. > > I emphasize again my concerns boil down to questions concerning > pattern inconsistencies. Thus, you may well have a good C++ answer > for the pattern inconsistency I noted above for example 21 when it > appears that fill in direct form (pls->plfill) may be used as a > callback, and also C++ answers for when fill, fill3, and gradient are > used directly throughout our examples and also potentially in a > multistream environment like example 14.
Alan, OK. On closer examination I think you may be right. Looking at the plfill code it does seem there is a potential problem. I'll look into this. Casting my mind back I seem to remember problems with the callbacks if they weren't static functions, so I may need to think about how this will work. Thanks for spotting the problem anyway! 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
