On 09/03/2007 10:49 PM, Andy Ross wrote: > A "const" char* is exactly the same thing as a regular pointer at > the level of CPU instructions.
Hmmmm. > Writing to it does exactly the > same thing as writing to a non-const pointer. 1) I assume "writing to it" means writing to the chars (not writing to the pointer). Dangling antecedents can be confusing. Perhaps "writing via the pointer" would be clearer than "writing to the pointer". 2) It seems vacuous to compare writing via a const char* to writing via a non-const char*, because AFAIK there is no such thing as writing via a const char*. No compiler AFAIK will generate any CPU instructions for it. Yes, you can have two pointers that are bitwise identical, one of which is const and the other of which is non-const. But if writing is being done (at the level of CPU instructions) then it wasn't const (at the level of c++ source). > The difference > exists at *compile* time only. If MSVC is complaining about it, > just adjust the warning level. No, please don't adjust the warning level; that would be the third-best or fourth-best option. It would be better to use a const_cast; that's what const_cast is for. But even that is second best; it would be preferable to fix the code, bottom up, so that no const_casts are necessary. > Are you maybe trying to say that plib is writing to a static > string constant? That would be a pretty serious bug if true, but > as far as I can see it's not. Your use of strdup() is just > adding an extra (and needless) step. Have you tried just adding > a typecast instead? That's a different issue. Let's assume we are talking about function arguments here. It can be understood by making a distinction between de-facto constant and declared const. a) If the function is passed a char* argument and doesn't use it to write to the chars, then we have a de-facto constant situation. b) If the arg is declared as a const char*, then we have a declared const situation. Declared const "should" imply de-facto constant, but doesn't really, because of the possibility of a const_cast. > Again, the point here isn't whether or not plib's code is clean > and will compile without warnings on MSVC. It is risky to talk about "the" point. There are multiple points to be considered. One point well worth considering is _correctness_. There is a distinction between de-facto correctness and provable correctness. The reason the "const" qualifier was invented was to make the proof of correctness easier. Sure, it is possible to prove correctness by eyeballing all the code to see whether it it writes to the chars via the char*, and for years people did it that way ... but why not let the compiler do it? The compiler is a lot better at it. If the belief is that some function (e.g. a plib function) is treating the chars as de-facto constant, far and away the easiest way to verify it is to declare the pointer as const char*. This is incomparably easier and more reliable than "adjusting the warning level" downwards and then eyeballing the code to see whether the pointer is really de-facto constant. In a project as large and complex as FG, provable correctness should be greatly preferred over believed-maybe-de-facto correctness. This also makes supposedly-open software more truly open. It means that if I fix a problem by cleaning up the declarations, the problem tends to /stay/ fixed for a long time. Not only is it easier for me (because I don't have to eyeball the code), it is also easier for the next guy, and the next guy, and the next.... > The point is whether > it works the same as it does on our other platforms. Provably works the same? Or usually-sorta works the same? ================================================================ It is amusing to contemplate the contrast between this thread and some other recent threads. a) Is it really appropriate to emphasize the naming of internal variables, vilifying some names as "too cute" and vilifying other names as "too ugly"? b) Is it really appropriate to lower the warning level and accept de-facto-probably constant as a substitute for declared const? Those priorities seem backwards, by a wide margin, for the following reasons: a) The incidence of programs that fail because a dummy index is spelled "ii" instead of of "i" is essentially zero. b) The incidence of programs that fail because a supposedly- constant object gets overwritten is substantial. That's why "const" was invented. Standard good practice is to 1) turn up the warning level as high as it will go, 2) get rid of all const_casts, and 3) fix things so that they compile without warnings. The larger and more complicated a project is, the more important it is to adhere to these good practices. An impending release makes it all the more important. Openness makes it even more important. The fix shouldn't even be hard. Given that the linux g++ compiler is not complaining, and given that MSVC is complaining about const/non-const conflicts -- i.e. the sort of thing that can be fixed with a strdup -- then it suggests that plib is not providing the same interface on the two platforms. The difference is probably accidental, due to a broken macro somewhere, or something like that. If it is not accidental, then the correctness is very much in doubt, and concealing the problem with a const_cast (or by ignoring warnings) would be a Bad Idea. It is within the realm of possibility that a strdup is needed on one platform but not on the other. If plib can't be fixed, a wrapper function might be a reasonable way to solve the problem. (Getting rid of the plib dependence altogether might be another reasonable solution, but that's a topic for another day.) ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
