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 > __________________________ > ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
