On 2016-02-24 14:18+1030 Jonathan Woithe wrote: > Hi Alan > > On Tue, Feb 23, 2016 at 11:00:24AM -0800, Alan W. Irwin wrote: [..] >> It appears everyone so far is happy with the context approach. >> Furthermore, it appears now with thread-local storage that the address of >> the context does not need to be an argument which makes life a lot >> simpler for our users. > > From my perspective as a user of plplot I think having the explicit context > argument in the C API has distinct advantages. [...] > I certainly understand the need to keep API changes to a minimum to avoid > inflicting undue pain on users. At the same time, while thread-local global > context storage may provide thread safety it means that people who require > multiple plot contexts could not achieve this unless they split their work > across multiple threads.
True. However, isn't being forced to use separate threads in order to (automatically) have separate PLplot contexts for each thread a relatively minor inconvenience compared to the very much larger user inconvenience required by adding a context address to most API calls? > On a related matter, the placement of the context argument at the end of the > argument list in the original proposal was intriging. Most libraries I've > used which include such an argument include it as the first argument and > this makes more sense to my brain at least. What is the rationale for > having it at the end of the list? Does it make it easier to support earlier > API versions which lack the new argument? If we did end up having to include a context address as an argument to every PLplot call, then I agree my initial choice of making that argument last is likely wrong, and it should be first instead. However, I also think this question is now likely moot (see my response to your question above). You also asked a question about our C++ API, but I will leave that answer to our C++ experts. 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 __________________________ ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
