From: Alan W. I. <ir...@be...> - 2011-03-11 01:03:36
|
On 2011-03-08 19:58-0800 Alan W. Irwin wrote: > On 2011-03-08 11:54-0800 Alan W. Irwin wrote: > >> I think cleaning up our libplplot interface by using the const >> modifier for arrays whenever appropriate would be a good idea. >> Obviously this change would require substantial propagation effort, >> and might even require a soversion bump (if it constitutes a >> backwards-incompatible API change). But a cleaner PLplot interface is >> worth having in my view. >> >> What do others here feel about this proposed change? > > I have already had one positive response off-list from Andrew on this > question so I have decided to start the process to see how far I can > get. > > For my local version of the PLplot code I have already modified our > API in plplot.h appropriately using swig-support/plplotcapi.i as a > guide for the ambiguous pointer argument cases. I am currently > working through all the source files in the src directory dealing with > the gcc compiler warnings and errors that resulted from that plplot.h > change. So far (about one-fourth the way through all the files) the > required src changes seem pretty straightforward. Thus, I am > currently hopeful that by Thursday I will have achieved my first goal > which is to get the C libraries and examples to build and run without > issues for this large change to plplot.h. After that, I plan to look > at what is required to propagate this "const" change to all our language > bindings. Hi Andrew: Please look at revision 11616 for my first pass at both C and C++ "const" API changes. I used "const" wherever our docbook documentation stated that we had an input array with no further checking unless there was an error or warning messaged generated by the compiler. This "const" change required some further internal changes to our C and C++ code to avoid both errors and warnings. I tended to keep the internal disruptions to our code to a minimum by using casts rather than propagating the "const" modifier to some of our internal routines. Somebody else may want to propagate this "const" change even further into our internal routines for the same reasons (marking of array argument that are input-only aids to understanding what is going on with the code) that motivate this change for our public API. Currently our swig-generated bindings have build errors with this "const" change so I have disabled those languages (python, java, lua, and octave) by default as a temporary measure so this change won't disrupt default builds of our svn trunk version. For that default build the results look good for the test_diff_psc target in the build tree; our language bindings and associated examples that are not generated by swig (C++, f77, f95, ada, adathick, ocaml, and D) give good results with this "const" change when compared with the C results. Thus the current status with this "const" change is "so far so good" at least on Linux with the gcc family of compilers. Tests for other platforms/compilers would be much appreciated. One thing that has puzzled me about the current results was I had to use specific casts for all C++ examples that called PLplot API with doubly-dimensioned arrays to avoid build errors for those examples. Singly-dimensioned arrays had no such issues for C++ (in fact there wasn't even a warning message). Andrew, could you take a look at this to see if there is some other thing we could do that would not demand this 2D array casting for C++ applications that use our C++ API? That would make this "const" change more palatable to our C++ users. My own priority right now is to deal with the swig-generated binding build errors so we can enable all languages by default again. After that I plan to deal with some compiler warning messages (unless someone else beats me to it) that are caused by the "const" change for the above languages that are not supported by swig. 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); PLplot scientific plotting software package (plplot.org); 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 __________________________ |