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 __________________________ 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
