@Phil (and other C++ enthusiasts here): There is a question for you at the end about redacted dimension arguments for the C++ case.
@Everybody: Normally for higher-level languages that treat arrays as first-class objects (i.e., _all_ the computer languages we support other than C, Tcl, and [strangely] C++, see below) that carry their dimension information along with them, we use a redacted PLplot API, where arguments containing a redundant dimension are removed from argument lists. So, for example, plline(n, x, y) gets called as plline(x,y), from Python, Fortran, etc. But for this and like cases what should be the rule for calculating the dimension argument (e.g., n in the plline arguments) for the corresponding C call and what sanity checks should be made concerning n? For our swig-generated bindings (e.g., Python, Jave, Octave, and Lua) n is calculated from the actual length of the first related array argument (e.g., the x argument for plline) and the sanity check is the length of the other related arrays (e.g., the y argument of plline) are checked whether they have the same length, and if not, an error occurs. And this model has propagated further to other high-level languages (e.g., at least to D) and perhaps all of them since the swig-generated bindings were implemented first. For our new Fortran binding the current status is the dimension information is usually taken from the first array and no further checking done of the dimensions of the other associated arrays, and I was starting the process of converting that bad model (lots of chance for user error there) to the above model. However, then I started to consider the extra burden this "sanity check" would impose on our Fortran users, I came up with the following cunning plan.... My new plan for handling redacted dimension arguments for the Fortran binding is simply to calculate n as the minimum dimension of the associated arrays with the only sanity check imposed on our users being that the resulting n > 0. I think this way of handling things is a good one because it still gives the users some type of plot (and no memory management issues) even if they screw up and have one associated array inadvertently shorter than the rest. I also think this change should be done for all our languages that redact dimension arguments from argument lists. If there is general agreement that would be a good goal to have, I am willing to take a further look at this in the long term or happily encourage from the sidelines if someone else wants to make these language bindings changes in the shorter term. I also realized when researching this post, that our C++ binding has no redaction of the n argument for plline (or presumably any other part of our C++ API). I assume this is because our C++ binding currently just uses C-style arrays, but although I have only minimal knowledge of C++ my quick google search found an article that stated "C++ provides an alternative array type as a standard container" which have more powerful capabilities (like carrying array information with the object than C-style arrays. @ Phil (and other C++ enthusiasts here): Could you comment on why we are not using this possibility which should allow redacted argument lists for our C++ binding and much less chance of user error due to array issues? If you are enthusiastic about choosing to use the more powerful array type in our C++ binding arguments, I would encourage you to go ahead and make that change. To ease the transition to the new kind of arrays in argument lists you would probably want to keep the non-redacted form available in overloaded form around for a while but only if a user specifically chooses it with a CMake option such as -DPL_DEPRECATED_cxx=ON (as a gentle reminder to users to move to the more powerful array API before it is too late and we remove the deprecated version that uses C-style arrays). 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=267308311&iu=/4140 _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
