From: Jerry <lan...@qw...> - 2011-03-08 10:16:38
|
I wonder if someone could take a look at the API documentation for pllegend which has some problems. For example, the parameter position is not described at all, and the parameters bg_color, bb_style, nrow, ncolumn all have the same description. Also, the Ada bindings are sensitive to whether * parameters are input arrays, output arrays, both input and output arrays, or output scalars, and the docs are the only (or easiest) way that I can figure this out. (How do C programmers know?). I don't see any mistakes in this respect yet but I thought I would mention it just in case. Jerry |
From: Alan W. I. <ir...@be...> - 2011-03-08 19:55:01
|
Hi Jerry: I have changed the subject line because after giving the (short) answer to your question I am evolving this discussion into a different direction that deserves a separate subject line. On 2011-03-08 02:51-0700 Jerry wrote: > I wonder if someone could take a look at the API documentation for pllegend which has some problems. For example, the parameter position is not described at all, and the parameters bg_color, bb_style, nrow, ncolumn all have the same description. It's on my agenda to fix that. > Also, the Ada bindings are sensitive to whether * parameters are input arrays, output arrays, both input and output arrays, or output scalars, and the docs are the only (or easiest) way that I can figure this out. (How do C programmers know?). I don't see any mistakes in this respect yet but I thought I would mention it just in case. The const modifier (used when the C array is input only) _should_ help you to figure that out. For example, I used const for all arrays in the pllegend case because they are all input-only. However, for lots of the other functions in our API, we have been sloppy about that issue. For example, almost all array arguments for our API are input only, but we have seldom used the const modifier to demonstrate that. 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? 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2011-03-09 03:58:35
|
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. 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 __________________________ |
From: Maurice L. <mj...@br...> - 2011-03-09 07:52:52
|
On Tuesday, March 8, 2011 at 19:58:26 (-0800) Alan W. Irwin writes: > 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. I just *have* to post the const-nazi bit here. Apologies to anyone who is offended by the portrayal (btw my mom's side of the family is German). I thought it was really funny. And, although sometimes it's a PITA, I do really like const. http://gamesfromwithin.com/the-const-nazi -- Maurice LeBrun |
From: Arjen M. <arj...@de...> - 2011-03-09 08:00:13
|
Hi Maurice, Alan, On 2011-03-09 08:53, Maurice LeBrun wrote: > On Tuesday, March 8, 2011 at 19:58:26 (-0800) Alan W. Irwin writes: > > 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. > > I just *have* to post the const-nazi bit here. Apologies to anyone who is > offended by the portrayal (btw my mom's side of the family is German). I > thought it was really funny. And, although sometimes it's a PITA, I do really > like const. > > http://gamesfromwithin.com/the-const-nazi > my C skills mostly predate the introduction of const, but perhaps this web page will clarify to me _how_ to use it. Frankly, I have been puzzled over the correct use/placement of the keyword and that has probably led to me never really looking into it. I agree though that if this will clarify the intended use of the arguments (if only to the human reader), we should use it. Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Alan W. I. <ir...@be...> - 2011-03-15 19:31:18
|
On 2011-03-15 10:32-0700 Alan W. Irwin wrote: > Of course, > we should give advice in the release notes on how to avoid those C > warnings (for the recent const modifier changes) with explicit casts while referring to > http://c-faq.com/ansi/constmismatch.html for the justification. To Hazen and Andrew: As of revision 11627 I have made an additional announcement in README.release to that effect. Feel free to change it if you know of a clearer way to make the same points for those developing apps and libraries that depend on libplplotd and/or libplplotcxxd. Hazen, that announcement anticipates that you will bump the soversions of libplplotd and libplplotcxxd during the release process because the widespread const modifier changes constitute a backwards-incompatible change to our API. Andrew, that announcement anticipates that you will make the C++ API change you discussed (and revert my explicit casts for the examples/c++ case). As you mentioned off list, that soversion bump gives us the opportunity to clean up some other parts of our API. I think that is an excellent idea, but I don't know exactly what you had in mind or how much time you have to implement such further changes before our next release so perhaps you should start a new thread with unique subject line concerning that. 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 __________________________ |
From: Andrew R. <and...@us...> - 2011-03-16 09:39:18
|
On Tue, Mar 15, 2011 at 12:31:10PM -0700, Alan Irwin wrote: > On 2011-03-15 10:32-0700 Alan W. Irwin wrote: > > > Of course, > > we should give advice in the release notes on how to avoid those C > > warnings (for the recent const modifier changes) with explicit casts while referring to > > http://c-faq.com/ansi/constmismatch.html for the justification. > > To Hazen and Andrew: > > As of revision 11627 I have made an additional announcement in > README.release to that effect. Feel free to change it if you > know of a clearer way to make the same points for those developing > apps and libraries that depend on libplplotd and/or libplplotcxxd. > > Hazen, that announcement anticipates that you will bump the soversions > of libplplotd and libplplotcxxd during the release process because the > widespread const modifier changes constitute a backwards-incompatible > change to our API. > > Andrew, that announcement anticipates that you will make the C++ API > change you discussed (and revert my explicit casts for the > examples/c++ case). > > As you mentioned off list, that soversion bump gives us the > opportunity to clean up some other parts of our API. I think that is > an excellent idea, but I don't know exactly what you had in mind or > how much time you have to implement such further changes before our > next release so perhaps you should start a new thread with unique > subject line concerning that. Well one thing that immediately springs to mind is removing the contents of src/pldeprecated.c . There may be other API changes that we have discussed. It would be worth a trawl back through the archives. Andrew |
From: Alan W. I. <ir...@be...> - 2011-03-23 21:47:16
|
On 2011-03-23 21:34-0000 Andrew Ross wrote: > [...]As of my last commit lua also produces > a clean diff report. Good work. Thanks! 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 __________________________ |
From: Andrew R. <and...@us...> - 2011-03-23 22:17:38
|
On Wed, Mar 23, 2011 at 02:47:04PM -0700, Alan Irwin wrote: > On 2011-03-23 21:34-0000 Andrew Ross wrote: > > > [...]As of my last commit lua also produces > > a clean diff report. > > Good work. Thanks! Another fine example of programming by analogy... Andrew |
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 __________________________ |
From: Alan W. I. <ir...@be...> - 2011-03-11 05:14:54
|
On 2011-03-10 17:03-0800 Alan W. Irwin wrote: > My own priority right now is to deal with the swig-generated binding > build errors so we can enable all languages by default again. It turns out that const modifiers can mess up typemap matching for the composite argument cases unless you put const into the typemap argument identifiers consistent with the C API arguments in plplotcapi.i. To avoid any ambiguity about this, I have decided to use const modifiers consistently for all Matrix (except for outMatrixCk) and Array types of typemaps (not just the composite typemaps). The result (revision 11618) is that Java now builds and gives results that are consistent with C. I have enabled Java by default because of this good result. This good swig result for Java bindings and examples gives me a lot of confidence that the remaining issues with Python, Lua, and Octave will be straightforward for me to sort out. 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 __________________________ |
From: Andrew R. <and...@us...> - 2011-03-12 11:55:26
|
On Thu, Mar 10, 2011 at 09:14:45PM -0800, Alan Irwin wrote: > On 2011-03-10 17:03-0800 Alan W. Irwin wrote: > >> My own priority right now is to deal with the swig-generated binding >> build errors so we can enable all languages by default again. > > It turns out that const modifiers can mess up typemap matching for > the composite argument cases unless you put const into the typemap > argument identifiers consistent with the C API arguments in > plplotcapi.i. To avoid any ambiguity about this, I have decided to > use const modifiers consistently for all Matrix (except for > outMatrixCk) and Array types of typemaps (not just the composite > typemaps). The result (revision 11618) is that Java now builds and > gives results that are consistent with C. I have enabled Java > by default because of this good result. > > This good swig result for Java bindings and examples gives me a lot of > confidence that the remaining issues with Python, Lua, and Octave will > be straightforward for me to sort out. This is good because it means we can avoid the overhead of copying back data in the typemaps where the arrays are marked as const. While the cost is generally small, it is one less thing to do. It is an example of why const might make a tangible difference to plplot. Andrew |
From: Alan W. I. <ir...@be...> - 2011-03-16 17:55:15
|
On 2011-03-16 09:38-0000 Andrew Ross wrote: > Well one thing that immediately springs to mind is removing the contents of > src/pldeprecated.c . Hi Andrew: Yes, please! We have long given notice in this case so there is no question. And adjust doc/docbook/src/api-obsolete.xml accordingly while you are at it. > There may be other API changes that we have discussed. It would be worth a > trawl back through the archives. Scanning through headers for some keywords may give some ideas. For example, I recently noticed in bindings/c++/plstream.h a whole list of functions with the comment // Deprecated versions of methods which use PLINT instead of bool Is it time for you to remove those? Also, searches for "deprecated", "compatability", and "backwards" in include/*.h show a number of possibilities for removal. The other question is whether mention of "deprecated" in the source code is sufficient notice to our users. For example, you might want to ease them into these removals by making the removals by default, but give them an option PL_DEPRECATED to keep all the old cruft just for this release with a well-publicized promise to remove that option (and all the associated cruft) early in the next release cycle. OTOH, you might not want to do that because it extends the period of uncertainty, gives more chance for errors to creep in due to that extra complication, and those who want to cling to the old ways will do so until the last minute in any case. I am going to leave all of these decisions (and the implementation and timing of that implementation) to you because I trust your judgement more than mine on these tricky API matters, and I also still have lots of time-consuming stuff left on my PLplot agenda before the release of 5.9.8 including extensive testing on the Linux, wine/MinGW/MSYS, wine/MinGW, and possibly even wine/Cygwin platforms. 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 __________________________ |
From: Andrew R. <and...@us...> - 2011-03-17 20:09:26
|
On Wed, Mar 16, 2011 at 10:55:04AM -0700, Alan Irwin wrote: > On 2011-03-16 09:38-0000 Andrew Ross wrote: > > > Well one thing that immediately springs to mind is removing the contents of > > src/pldeprecated.c . > > Hi Andrew: > > Yes, please! We have long given notice in this case so there is no > question. And adjust doc/docbook/src/api-obsolete.xml accordingly > while you are at it. Done. > > > There may be other API changes that we have discussed. It would be worth a > > trawl back through the archives. > > Scanning through headers for some keywords may give some ideas. For > example, I recently noticed in bindings/c++/plstream.h a whole list of > functions with the comment > > // Deprecated versions of methods which use PLINT instead of bool > > Is it time for you to remove those? I'll think about this one. > Also, searches for "deprecated", "compatability", and "backwards" in > include/*.h show a number of possibilities for removal. I've removed a number of macros (e.g. for plcol) which have been marked as obsolete for some time. Plplot code + examples updated accordingly. > The other question is whether mention of "deprecated" in the source > code is sufficient notice to our users. For example, you might want > to ease them into these removals by making the removals by default, > but give them an option PL_DEPRECATED to keep all the old cruft just > for this release with a well-publicized promise to remove that option > (and all the associated cruft) early in the next release cycle. OTOH, > you might not want to do that because it extends the period of > uncertainty, gives more chance for errors to creep in due to that > extra complication, and those who want to cling to the old ways will > do so until the last minute in any case. I've moved a number of such functions into pldeprecated and added a runtime warning. This file (and associated C++ and fortran bindings) are wrapped in #ifdef PL_DEPRECATED. You need to explicitly add this to the cmake command line to get support. This should push users into updating code. This puts a formal system in place for deprecating functions and then removing them at a later release. > I am going to leave all of these decisions (and the implementation and > timing of that implementation) to you because I trust your judgement > more than mine on these tricky API matters, and I also still have lots > of time-consuming stuff left on my PLplot agenda before the release of > 5.9.8 including extensive testing on the Linux, wine/MinGW/MSYS, > wine/MinGW, and possibly even wine/Cygwin platforms. Please test this. User reports useful too. This is quite a change and a number of the old functions such as plcol still appeared dotted around the plplot code so I suspect users may be affected too. Andrew |
From: Alan W. I. <ir...@be...> - 2011-03-13 21:10:51
|
On 2011-03-10 21:14-0800 Alan W. Irwin wrote: > This good swig result for Java bindings and examples gives me a lot of > confidence that the remaining issues with Python, Lua, and Octave will > be straightforward for me to sort out. Hi Andrew: I now (revision 11621) have good results (no errors, no warning messages related to const, and the same C comparison results as before) for all languages with Swig-generated bindings. The last one (Octave) was much more difficult than the rest because of all the special my_* API variants that are present in our current Octave bindings. Could you please put on your ToDo list to take a critical look at these my_* API variants for Octave? I suspect a number of those are not that useful and could be dropped so that we could have simpler and easier-to-maintain Octave bindings going forward. I have also decided (revision 11622) to retire the matwrapped Octave bindings. The swig-generated Octave bindings are superior in all respects that I am aware of. Also, I certainly don't want to deal with const issues (whatever those might be) for the matwrapped Octave bindings, and I doubt anybody else wants to do that either. This completes the swig-related part of the const modifier project although to finish off the entire project there are still some const-related compiler warnings I will be dealing with. 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2011-03-14 20:55:05
|
To the C/C++ gurus here: Because of all the gcc warnings and g++ errors (more about that later) I was getting unless I used explicit casts with e.g, const PLFLT ** arguments I became concerned that perhaps I was misinterpreting the meaning of const PLFLT ** z; Some googling this morning found the answer at http://stackoverflow.com/questions/336585/what-does-a-const-pointer-to-pointer-mean-in-c-and-in-c The discussion there pointed to http://c-faq.com/decl/spiral.anderson.html which I think you will all find an interesting read. Both sources confirm my original interpretation was correct. The answer is z is a mutable pointer to a mutable pointer to an immutable PLFLT. Therefore, such declarations for our function arguments claim that our functions are not changing the values of the doubly dimensioned z array which I believe is exactly what we want. Similarly, const PLFLT *x; arguments for our functions claim that our functions are not changing the values of the singly dimensioned x array which again I believe is exactly what we want. The above is useful background to the fundamental issue that bothers me which is automatic casting from mutable to immutable of singly dimensioned and doubly dimensioned arrays are treated quite differently by both gcc and g++. For an example of this with plline3, see examples/c/x18c.c where mutable x, y, and z singly dimensions array arguments are automatically cast to immutable without a warning message. I think that lack of warning message is the correct thing to do since obviously x, y, and z must be assigned values before calling plline3 so it makes no sense for gcc to warn about the automatic casting of each of those PLFLT * arrays to const PLFLT *. However, such sanity does not prevail for the doubly dimensioned array case; there you must explicitly use (const PLFLT **) casts to avoid warning messages from the gcc C compiler and error (!) messages from the gcc C++ compiler for the doubly dimensioned arrays, see examples/c/x11c.c and examples/c++/x11.cc. Does any C/C++ guru here know how to avoid those explicit casts for each of our doubly dimensioned arguments? I don't think I should revert the const project since there are reasons of documentation and safety to justify it (see http://www.cprogramming.com/tutorial/const_correctness.html). Nevertheless, if those explicit casts are required it will be inconvenient for our users so if it is possible to avoid that work, let's help at least our new users out with good examples. Note, this doubly dimensioned issue may be just a quirk with gcc and g++ being inconveniently restrictive about automatic casting from PLFLT ** to const PLFLT** without a warning (gcc) or error (g++) message, and other C and C++ compilers may have different quirks or errors concerning the interpretation of const. So it would be a good idea for those here with access to non-gcc compilers to run the test_diff_psc target with BUILD_TEST=ON and report back all warning or error messages that are related to our const arguments. Better to find out now about any platform problems introduced by the const modifier project rather than one day after our next release! 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2011-03-20 01:33:47
|
On 2011-03-17 20:09-0000 Andrew Ross wrote: > On Wed, Mar 16, 2011 at 10:55:04AM -0700, Alan Irwin wrote: >> On 2011-03-16 09:38-0000 Andrew Ross wrote: >> >>> Well one thing that immediately springs to mind is removing the contents of >>> src/pldeprecated.c . >> >> Hi Andrew: >> >> Yes, please! We have long given notice in this case so there is no >> question. And adjust doc/docbook/src/api-obsolete.xml accordingly >> while you are at it. > > Done. > >> >>> There may be other API changes that we have discussed. It would be worth a >>> trawl back through the archives. >> >> Scanning through headers for some keywords may give some ideas. For >> example, I recently noticed in bindings/c++/plstream.h a whole list of >> functions with the comment >> >> // Deprecated versions of methods which use PLINT instead of bool >> >> Is it time for you to remove those? > > I'll think about this one. > >> Also, searches for "deprecated", "compatability", and "backwards" in >> include/*.h show a number of possibilities for removal. > > I've removed a number of macros (e.g. for plcol) which have been marked as > obsolete for some time. Plplot code + examples updated accordingly. > >> The other question is whether mention of "deprecated" in the source >> code is sufficient notice to our users. For example, you might want >> to ease them into these removals by making the removals by default, >> but give them an option PL_DEPRECATED to keep all the old cruft just >> for this release with a well-publicized promise to remove that option >> (and all the associated cruft) early in the next release cycle. OTOH, >> you might not want to do that because it extends the period of >> uncertainty, gives more chance for errors to creep in due to that >> extra complication, and those who want to cling to the old ways will >> do so until the last minute in any case. > > I've moved a number of such functions into pldeprecated and added a > runtime warning. This file (and associated C++ and fortran bindings) are > wrapped in #ifdef PL_DEPRECATED. You need to explicitly add this to > the cmake command line to get support. This should push users into > updating code. This puts a formal system in place for deprecating > functions and then removing them at a later release. > >> I am going to leave all of these decisions (and the implementation and >> timing of that implementation) to you because I trust your judgement >> more than mine on these tricky API matters, and I also still have lots >> of time-consuming stuff left on my PLplot agenda before the release of >> 5.9.8 including extensive testing on the Linux, wine/MinGW/MSYS, >> wine/MinGW, and possibly even wine/Cygwin platforms. > > Please test this. User reports useful too. This is quite a change and > a number of the old functions such as plcol still appeared dotted > around the plplot code so I suspect users may be affected too. Wow! Thanks for all this extirpation and deprecation work! As of revision 11659 I have done some additional plcol extirpation/replacement by plcol0, and dealt with some independent bit-rot revealed by my preliminary tests. I have just completed 7 comprehensive tests for the shared configuration type. These consist of ctest, and 3 versions (build tree, installed examples tree and traditional installed examples tree) of the test_noninteractive and test_interactive targets. The results show no obvious errors. Furthermore, grep -v 'java/x' \ ../comprehensive_test_disposeable/shared/output_tree/*.out |\ grep -v problems | \ grep -v WARNING | \ grep -v 'x[0-9][0-9].java:' | \ grep -i warning (where all the -v stanzas are to get rid of java warnings, cmake WARNINGs, and PLplot run-time WARNING messages) show no build-time warnings from C/C++ compilers (a nice improvement!), and only gives this remaining stupid octave run-time warnings: ../comprehensive_test_disposeable/shared/output_tree/ctest.out:6: warning: split is obsolete and will be removed from a future version of Octave; please use strsplit instead etc. I think changing split to strsplit in plplot_test/test_octave.sh.in should fix this octave run-time issue, but I don't understand the strsplit syntax for octave. Would you have a go at that change, please, to remove this irritating warning? Here is the current status of the languages that don't have a perfect diff report: x29c octave Missing examples : 19 Differing postscript output : Missing stdout : Differing stdout : ada Missing examples : 33 Differing postscript output : 26 27 Missing stdout : Differing stdout : adathick Missing examples : 33 Differing postscript output : 26 27 Missing stdout : Differing stdout : ocaml Missing examples : 33 Differing postscript output : Missing stdout : Differing stdout : lua Missing examples : 33 Differing postscript output : 04 19 26 Missing stdout : Differing stdout : d Missing examples : 33 Differing postscript output : 04 26 Missing stdout : Differing stdout : Jerry has recently done all the hard pllegend, plstring, and plstring3 API work so the remaining Ada examples 26, 27, and 33 issues should be straightforward to fix for him, and similarly for Hez and OCaml example 33. I am going to try to perfect lua in the next day or so (except for example 19). So the difference issues should continue to be reduced in the next little while. I am pleased with all this progress toward what I hope is going to be a perfect diff report for this release. 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2011-03-20 07:54:34
|
On 2011-03-19 18:33-0700 Alan W. Irwin wrote: > I have just completed 7 > comprehensive tests for the shared configuration type. These consist > of ctest, and 3 versions (build tree, installed examples tree and > traditional installed examples tree) of the test_noninteractive and > test_interactive targets. The results > show no obvious errors. > Furthermore, > > grep -v 'java/x' \ > ../comprehensive_test_disposeable/shared/output_tree/*.out |\ > grep -v problems | \ > grep -v WARNING | \ > grep -v 'x[0-9][0-9].java:' | \ > grep -i warning > > (where all the -v stanzas are to get rid of java warnings, cmake > WARNINGs, and PLplot run-time WARNING messages) show no build-time warnings from > C/C++ compilers (a nice improvement!), and only gives this remaining stupid > octave run-time warnings: > > ../comprehensive_test_disposeable/shared/output_tree/ctest.out:6: > warning: split is obsolete and will be removed from a future version > of Octave; please use strsplit instead > > etc. I think changing split to strsplit in > plplot_test/test_octave.sh.in should fix this octave run-time issue, > but I don't understand the strsplit syntax for octave. Would you have > a go at that change, please, to remove this irritating warning? Hi Andrew: I extended the test to 21 tests involving the shared, nondynamic, and static major configuration options. There was one memory management issue I discovered with qt_example which I worked around by permanently setting -DPLD_extqt=OFF for the case when dynamic devices are not enabled (i.e., the nondynamic and static cases). I don't know whether that is a regression or a memory management problem we have had for a long time with extqt for the case where the qt device driver is part of libplplotd rather than a separate shared object. After that fix, all was well. The only additional build type of warning I got was, e.g, comprehensive_test_disposeable/static/output_tree/installed_make_interactive.out:/home/software/plplot_svn/HEAD/plplot_cmake_qt/drivers/tk.c:1529: warning: the use of tmpnam' is dangerous, better use mkstemp' IIRC you have already attempted to eliminate as many of those as possible so I believe we are stuck with these remaining build warnings. All in all, I am pleased with the results of these 21 tests on my Debian squeeze platform. Note, I encourage others to run those same 21 tests on their own platforms. Here is how I did that here. software@raven> scripts/comprehensive_test.sh --prefix \ /home/software/plplot_svn/HEAD/comprehensive_test_disposeable \ --cmake_added_options "-DPLD_pdf=ON" Easy isn't it.... :-) Note, however, you will need a lot (!) of free disk space. software@raven> du -sh ../comprehensive_test_disposeable/ 35G ../comprehensive_test_disposeable/ ^^^ and if you don't use the -do_test_interactive no option for the above script, you will have to stick around for a couple of hours to click on various interactive tests near the end of each of the three shared, nondynamic, and static portions to allow those interactive tests to complete. So bring a book to read. 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 __________________________ |
From: Andrew R. <and...@us...> - 2011-03-20 22:54:49
|
On Sat, Mar 19, 2011 at 06:33:39PM -0700, Alan Irwin wrote: > On 2011-03-17 20:09-0000 Andrew Ross wrote: > > > Please test this. User reports useful too. This is quite a change and > > a number of the old functions such as plcol still appeared dotted > > around the plplot code so I suspect users may be affected too. > > Wow! Thanks for all this extirpation and deprecation work! > > As of revision 11659 I have done some additional plcol > extirpation/replacement by plcol0, and dealt with some independent > bit-rot revealed by my preliminary tests. I have just completed 7 > comprehensive tests for the shared configuration type. These consist > of ctest, and 3 versions (build tree, installed examples tree and > traditional installed examples tree) of the test_noninteractive and > test_interactive targets. The results > show no obvious errors. > Furthermore, > > grep -v 'java/x' \ > ../comprehensive_test_disposeable/shared/output_tree/*.out |\ > grep -v problems | \ > grep -v WARNING | \ > grep -v 'x[0-9][0-9].java:' | \ > grep -i warning > > (where all the -v stanzas are to get rid of java warnings, cmake > WARNINGs, and PLplot run-time WARNING messages) show no build-time warnings from > C/C++ compilers (a nice improvement!), and only gives this remaining stupid > octave run-time warnings: > > ../comprehensive_test_disposeable/shared/output_tree/ctest.out:6: > warning: split is obsolete and will be removed from a future version > of Octave; please use strsplit instead > > etc. I think changing split to strsplit in > plplot_test/test_octave.sh.in should fix this octave run-time issue, > but I don't understand the strsplit syntax for octave. Would you have > a go at that change, please, to remove this irritating warning? I can do so easily. The reason I didn't is that strsplit was only introduced in octave 3.2 so doing so would require bumping our minimum octave version requirements for a relatively minor reason. Now octave 3.4 has been released though it might be the time for this change. > > Here is the current status of the languages that don't have a > perfect diff report: > > octave > Missing examples : 19 > Differing postscript output : > Missing stdout : > Differing stdout : > > Jerry has recently done all the hard pllegend, plstring, and plstring3 > API work so the remaining Ada examples 26, 27, and 33 issues should be > straightforward to fix for him, and similarly for Hez and OCaml > example 33. I am going to try to perfect lua in the next day or so > (except for example 19). So the difference issues should continue to > be reduced in the next little while. I am pleased with all this > progress toward what I hope is going to be a perfect diff report > for this release. Octave example 19 is now (finally!) implemented. Callbacks were easier than I anticipated. I just used a C wrapper for each callback function type. The approach is very similar to that used for Java. This might be a useful reference for lua if anyone fancies trying it. It is nice to finally have a clean diff report for octave. There is still some work to do here to implement the other callbacks, but the technically difficult bit has now been done. Andrew |
From: Alan W. I. <ir...@be...> - 2011-03-21 04:10:00
|
On 2011-03-20 22:54-0000 Andrew Ross wrote: > Octave example 19 is now (finally!) implemented. Hi Andrew: Good work! I am really happy to see that perfect octave result which we have never had before. I am making some good progress with Lua and pllegend. The pllegend API was easy to implement in Lua. Lua example 4 now gives the same results as the corresponding C example. I plan to follow up with updating Lua example 26 and implementing Lua example 33. I would appreciate it if someone more familiar than I am with example 19 issues would deal with that for Lua. 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2011-03-21 21:56:59
|
This thread has long evolved from its origins concerning the const modifier so I have changed the subject line to something more appropriate. On 2011-03-20 21:09-0700 Alan W. Irwin wrote: > I am making some good progress with Lua and pllegend. The pllegend > API was easy to implement in Lua. Lua example 4 now gives the same > results as the corresponding C example. I plan to follow up with > updating Lua example 26 and implementing Lua example 33. Done as of revision 11670. Here is the resulting Lua diff report. lua Missing examples : Differing postscript output : 19 Missing stdout : Differing stdout : > I would appreciate it if someone more familiar than I am with example > 19 issues would deal with that for Lua. I repeat that sentiment. My next planned step is to take a look at the pllegend D issues to see if I can make any progress there using my tried and true "programming by analogy" trick when I know little about a language. 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 __________________________ |
From: Andrew R. <and...@us...> - 2011-03-14 21:48:05
|
Alan, No - gcc is correct in warning about this, at least for C. An explanation is given at http://c-faq.com/ansi/constmismatch.html The problem is with the way C (and C++) define 2-d arrays as a pointer to an array of pointers. const PLFLT **z only guarantees that the values of z don't change, but allows the array of pointers to be modified. Clearly that can lead to problems, hence the warning. On the other hand implicitly casting PLFT * to const PLFLT * is safe. C++ lets you do something like const PLFLT * const * which guarantees both the data and the array of pointers won't change. You can safely implicitly cast a PLFLT ** to this. C is more restrictive and won't let you do this. So in answer to your question, in C you do need the explicit cast, although you can do away with it in C++ by using const twice. Not one of the best designed features of C. Andrew On Mon, Mar 14, 2011 at 01:54:56PM -0700, Alan Irwin wrote: > To the C/C++ gurus here: > > Because of all the gcc warnings and g++ errors (more about that later) > I was getting unless I used explicit casts with e.g, const PLFLT ** > arguments I became concerned that perhaps I was misinterpreting the > meaning of > > const PLFLT ** z; > > Some googling this morning found the answer at > http://stackoverflow.com/questions/336585/what-does-a-const-pointer-to-pointer-mean-in-c-and-in-c > The discussion there pointed to > http://c-faq.com/decl/spiral.anderson.html which I think you will all > find an interesting read. Both sources confirm my original > interpretation was correct. > > The answer is z is a mutable pointer to a mutable pointer to an > immutable PLFLT. Therefore, such declarations for our function > arguments claim that our functions are not changing the values of the > doubly dimensioned z array which I believe is exactly what we want. > Similarly, > > const PLFLT *x; > > arguments for our functions claim that our functions are not changing > the values of the singly dimensioned x array which again I believe is > exactly what we want. > > The above is useful background to the fundamental issue that bothers > me which is automatic casting from mutable to immutable of singly > dimensioned and doubly dimensioned arrays are treated quite > differently by both gcc and g++. > > For an example of this with plline3, see examples/c/x18c.c where > mutable x, y, and z singly dimensions array arguments are > automatically cast to immutable without a warning message. I think > that lack of warning message is the correct thing to do since > obviously x, y, and z must be assigned values before calling plline3 > so it makes no sense for gcc to warn about the automatic casting of > each of those PLFLT * arrays to const PLFLT *. However, such sanity > does not prevail for the doubly dimensioned array case; there you must > explicitly use (const PLFLT **) casts to avoid warning messages from > the gcc C compiler and error (!) messages from the gcc C++ compiler > for the doubly dimensioned arrays, see examples/c/x11c.c and > examples/c++/x11.cc. > > Does any C/C++ guru here know how to avoid those explicit casts for > each of our doubly dimensioned arguments? I don't think I should > revert the const project since there are reasons of documentation and > safety to justify it (see > http://www.cprogramming.com/tutorial/const_correctness.html). > Nevertheless, if those explicit casts are required it will be > inconvenient for our users so if it is possible to avoid that work, > let's help at least our new users out with good examples. > > Note, this doubly dimensioned issue may be just a quirk with gcc and > g++ being inconveniently restrictive about automatic casting from > PLFLT ** to const PLFLT** without a warning (gcc) or error (g++) > message, and other C and C++ compilers may have different quirks or > errors concerning the interpretation of const. So it would be a good > idea for those here with access to non-gcc compilers to run the > test_diff_psc target with BUILD_TEST=ON and report back all warning or > error messages that are related to our const arguments. > > Better to find out now about any platform problems introduced by the > const modifier project rather than one day after our next release! > > 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 > __________________________ > |
From: Alan W. I. <ir...@be...> - 2011-03-15 00:37:33
|
On 2011-03-14 21:47-0000 Andrew Ross wrote: > > Alan, > > No - gcc is correct in warning about this, at least for C. An explanation > is given at > http://c-faq.com/ansi/constmismatch.html > > The problem is with the way C (and C++) define 2-d arrays as a pointer to > an array of pointers. const PLFLT **z only guarantees that the values of > z don't change, but allows the array of pointers to be modified. Hi Andrew: Thanks for finding the above URL. It took me some rereads, but I think I understand it now. What is being demonstrated by the example at the above URL is that conversion from type ** to const type ** might allow additional subtle errors to creep in which are not possible with a conversion from type * to const type *. So the C/C++ standard demands (via warnings for C and errors for C++) that explicit casts must be used to convert type ** to const type ** not only in assignment statements (I can accept that) but also for arguments to functions (I am not happy with that). I took special exception to the last paragraph of the above article in the context of function arguments: <quote> In C, if you must assign or pass pointers which have qualifier mismatches at other than the first level of indirection, you must use explicit casts (e.g. (const char **) in this case), although as always, the need for such a cast may indicate a deeper problem which the cast doesn't really fix. </quote> I absolutely hate this sort of "prior restraint" for function arguments. Obviously, when we advertise an argument to one of the PLplot functions as const PLFLT ** (or const PLFLT * for that matter) we are making promises not to screw up by changing those array values. However, the whole thrust of the above URL is there is a subtle extra possibility for us to screw up in the doubly dimensioned case so our users must use make-work explicit casts (inconsistently in the doubly dimensioned case, but not in the singly dimensioned one) to remind them of the possibility that we _might_ be falsely advertising. And those explicit casts don't protect them in the slightest if we do screw up. I am not happy with this situation (to strongly understate the case), but I guess all C/C++ programmers are stuck with this "standard". I still feel it is the right thing to do to advertise that we don't change the values of our singly or doubly dimensioned array arguments. However, when discussing the const modifier API change in README.release I will refer to the above URL to try to avert the wrath of our users because of this extra explicit casting work that will be required from them from now on by the C/C++ standards. Alan > > On Mon, Mar 14, 2011 at 01:54:56PM -0700, Alan Irwin wrote: >> To the C/C++ gurus here: >> >> Because of all the gcc warnings and g++ errors (more about that later) >> I was getting unless I used explicit casts with e.g, const PLFLT ** >> arguments I became concerned that perhaps I was misinterpreting the >> meaning of >> >> const PLFLT ** z; >> >> Some googling this morning found the answer at >> http://stackoverflow.com/questions/336585/what-does-a-const-pointer-to-pointer-mean-in-c-and-in-c >> The discussion there pointed to >> http://c-faq.com/decl/spiral.anderson.html which I think you will all >> find an interesting read. Both sources confirm my original >> interpretation was correct. >> >> The answer is z is a mutable pointer to a mutable pointer to an >> immutable PLFLT. Therefore, such declarations for our function >> arguments claim that our functions are not changing the values of the >> doubly dimensioned z array which I believe is exactly what we want. >> Similarly, >> >> const PLFLT *x; >> >> arguments for our functions claim that our functions are not changing >> the values of the singly dimensioned x array which again I believe is >> exactly what we want. >> >> The above is useful background to the fundamental issue that bothers >> me which is automatic casting from mutable to immutable of singly >> dimensioned and doubly dimensioned arrays are treated quite >> differently by both gcc and g++. >> >> For an example of this with plline3, see examples/c/x18c.c where >> mutable x, y, and z singly dimensions array arguments are >> automatically cast to immutable without a warning message. I think >> that lack of warning message is the correct thing to do since >> obviously x, y, and z must be assigned values before calling plline3 >> so it makes no sense for gcc to warn about the automatic casting of >> each of those PLFLT * arrays to const PLFLT *. However, such sanity >> does not prevail for the doubly dimensioned array case; there you must >> explicitly use (const PLFLT **) casts to avoid warning messages from >> the gcc C compiler and error (!) messages from the gcc C++ compiler >> for the doubly dimensioned arrays, see examples/c/x11c.c and >> examples/c++/x11.cc. >> >> Does any C/C++ guru here know how to avoid those explicit casts for >> each of our doubly dimensioned arguments? I don't think I should >> revert the const project since there are reasons of documentation and >> safety to justify it (see >> http://www.cprogramming.com/tutorial/const_correctness.html). >> Nevertheless, if those explicit casts are required it will be >> inconvenient for our users so if it is possible to avoid that work, >> let's help at least our new users out with good examples. >> >> Note, this doubly dimensioned issue may be just a quirk with gcc and >> g++ being inconveniently restrictive about automatic casting from >> PLFLT ** to const PLFLT** without a warning (gcc) or error (g++) >> message, and other C and C++ compilers may have different quirks or >> errors concerning the interpretation of const. So it would be a good >> idea for those here with access to non-gcc compilers to run the >> test_diff_psc target with BUILD_TEST=ON and report back all warning or >> error messages that are related to our const arguments. >> >> Better to find out now about any platform problems introduced by the >> const modifier project rather than one day after our next release! >> >> 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 >> __________________________ >> > __________________________ 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 __________________________ |
From: Andrew R. <and...@us...> - 2011-03-15 13:25:44
|
Alan, For the C++ case I will make the required changes so the C++ wrapper has const PLFLT * const * in . This way explicit casting is not required. BTW a quick test case will show that this is fine if you compile with g++, but generates warnings with gcc - as expected from the relevant standards. One other way would be to include the const in a comment in the definition, i.e. something like /* const */ PLFLT **zarray. That way anyone looking at the code can see the intent, but we don't actually get into the messy area of explicit casting. This is a bit of a cop-out, but would avoid the need for existing code to be modified. Andrew On Mon, Mar 14, 2011 at 05:37:25PM -0700, Alan Irwin wrote: > On 2011-03-14 21:47-0000 Andrew Ross wrote: > >> >> Alan, >> >> No - gcc is correct in warning about this, at least for C. An explanation >> is given at >> http://c-faq.com/ansi/constmismatch.html >> >> The problem is with the way C (and C++) define 2-d arrays as a pointer to >> an array of pointers. const PLFLT **z only guarantees that the values of >> z don't change, but allows the array of pointers to be modified. > > Hi Andrew: > > Thanks for finding the above URL. > > It took me some rereads, but I think I understand it now. What is > being demonstrated by the example at the above URL is that conversion > from type ** to const type ** might allow additional subtle errors to > creep in which are not possible with a conversion from type * to const > type *. So the C/C++ standard demands (via warnings for C and errors > for C++) that explicit casts must be used to convert type ** to const > type ** not only in assignment statements (I can accept that) but also > for arguments to functions (I am not happy with that). > > I took special exception to the last paragraph of the above article > in the context of function arguments: > > <quote> > In C, if you must assign or pass pointers which have qualifier > mismatches at other than the first level of indirection, you must use > explicit casts (e.g. (const char **) in this case), although as > always, the need for such a cast may indicate a deeper problem which > the cast doesn't really fix. > </quote> > > I absolutely hate this sort of "prior restraint" for function > arguments. Obviously, when we advertise an argument to one of the > PLplot functions as const PLFLT ** (or const PLFLT * for that matter) > we are making promises not to screw up by changing those array values. > However, the whole thrust of the above URL is there is a subtle extra > possibility for us to screw up in the doubly dimensioned case so our > users must use make-work explicit casts (inconsistently in the doubly > dimensioned case, but not in the singly dimensioned one) to remind > them of the possibility that we _might_ be falsely advertising. And > those explicit casts don't protect them in the slightest if we do > screw up. I am not happy with this situation (to strongly understate > the case), but I guess all C/C++ programmers are stuck with this > "standard". > > I still feel it is the right thing to do to advertise that we don't > change the values of our singly or doubly dimensioned array arguments. > However, when discussing the const modifier API change in > README.release I will refer to the above URL to try to avert the wrath > of our users because of this extra explicit casting work that will be > required from them from now on by the C/C++ standards. > > Alan > >> >> On Mon, Mar 14, 2011 at 01:54:56PM -0700, Alan Irwin wrote: >>> To the C/C++ gurus here: >>> >>> Because of all the gcc warnings and g++ errors (more about that later) >>> I was getting unless I used explicit casts with e.g, const PLFLT ** >>> arguments I became concerned that perhaps I was misinterpreting the >>> meaning of >>> >>> const PLFLT ** z; >>> >>> Some googling this morning found the answer at >>> http://stackoverflow.com/questions/336585/what-does-a-const-pointer-to-pointer-mean-in-c-and-in-c >>> The discussion there pointed to >>> http://c-faq.com/decl/spiral.anderson.html which I think you will all >>> find an interesting read. Both sources confirm my original >>> interpretation was correct. >>> >>> The answer is z is a mutable pointer to a mutable pointer to an >>> immutable PLFLT. Therefore, such declarations for our function >>> arguments claim that our functions are not changing the values of the >>> doubly dimensioned z array which I believe is exactly what we want. >>> Similarly, >>> >>> const PLFLT *x; >>> >>> arguments for our functions claim that our functions are not changing >>> the values of the singly dimensioned x array which again I believe is >>> exactly what we want. >>> >>> The above is useful background to the fundamental issue that bothers >>> me which is automatic casting from mutable to immutable of singly >>> dimensioned and doubly dimensioned arrays are treated quite >>> differently by both gcc and g++. >>> >>> For an example of this with plline3, see examples/c/x18c.c where >>> mutable x, y, and z singly dimensions array arguments are >>> automatically cast to immutable without a warning message. I think >>> that lack of warning message is the correct thing to do since >>> obviously x, y, and z must be assigned values before calling plline3 >>> so it makes no sense for gcc to warn about the automatic casting of >>> each of those PLFLT * arrays to const PLFLT *. However, such sanity >>> does not prevail for the doubly dimensioned array case; there you must >>> explicitly use (const PLFLT **) casts to avoid warning messages from >>> the gcc C compiler and error (!) messages from the gcc C++ compiler >>> for the doubly dimensioned arrays, see examples/c/x11c.c and >>> examples/c++/x11.cc. >>> >>> Does any C/C++ guru here know how to avoid those explicit casts for >>> each of our doubly dimensioned arguments? I don't think I should >>> revert the const project since there are reasons of documentation and >>> safety to justify it (see >>> http://www.cprogramming.com/tutorial/const_correctness.html). >>> Nevertheless, if those explicit casts are required it will be >>> inconvenient for our users so if it is possible to avoid that work, >>> let's help at least our new users out with good examples. >>> >>> Note, this doubly dimensioned issue may be just a quirk with gcc and >>> g++ being inconveniently restrictive about automatic casting from >>> PLFLT ** to const PLFLT** without a warning (gcc) or error (g++) >>> message, and other C and C++ compilers may have different quirks or >>> errors concerning the interpretation of const. So it would be a good >>> idea for those here with access to non-gcc compilers to run the >>> test_diff_psc target with BUILD_TEST=ON and report back all warning or >>> error messages that are related to our const arguments. >>> >>> Better to find out now about any platform problems introduced by the >>> const modifier project rather than one day after our next release! >>> >>> 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 >>> __________________________ >>> >> > > __________________________ > 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 > __________________________ > |
From: Alan W. I. <ir...@be...> - 2011-03-15 17:33:05
|
On 2011-03-15 13:25-0000 Andrew Ross wrote: > > Alan, > > For the C++ case I will make the required changes so the C++ wrapper > has const PLFLT * const * in . This way explicit casting is not > required. Hi Andrew: Now that I have cooled down from my anger and dismay at what the C standard requires for immutable doubly dimensioned arrays, I do realize that most C libraries do not have such arrays as arguments. PLplot is quite unique in having so many of them, and presumably it was difficult for the C standards committee to anticipate our unique needs. Thanks in advance for your planned C++ bindings change. From what you say it appears you will be able to revert my explicit casting changes in examples/c++ without build errors which was my principal concern. If you look in the svn book, there is a method given there to do such wholesale reversions without having to edit the code in examples/c++. I will hold off on a planned stylings update until you are done to simplify that reversion. Your planned change means rebuilds of old libraries and apps against the next release of PLplot should just work without build errors and with no source code changes required for those libraries and apps. Of course, there will be build warnings from the C compiler for every doubly dimensioned PLplot API argument for every C app or library that depends on PLplot, but I think that result is acceptable. Of course, we should give advice in the release notes on how to avoid those C warnings with explicit casts while referring to http://c-faq.com/ansi/constmismatch.html for the justification. 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 __________________________ |