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 > __________________________ > ------------------------------------------------------------------------------ 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
