On Sat, 19 Apr 2008 21:45:49 +0200 NotFound <[EMAIL PROTECTED]> wrote:
Hi! > I faced the same problem when trying to get rid of some warnings in > order to help cage cleaning. Adding or removing a const in the > parameters of many functions becomes a design change, not a simple > code cleaning. If you add a cast to remove a warning, when the called > function get fixed a new warning appears about the now unnecessary > cast. In a perfect world, de-constification casts would never be necessary. They just hide the problem, they don't solve anything. So I try to avoid them. Unless I've seriously misunderstood things, "const" is a contract saying, "I will not modify the data you give me". The compiler takes that and says "oh, if the data won't be modified, that means I don't have to check it afterward, so I can merge conditionals and optimize things a little bit more." But when you pass that data (with or without a cast) to something else which modifies it, you've broken the contract. Seems like this problem typically crops up when a function in the middle of the call stack has a const parameter, but then tries to pass it to another, non-const function. So as a general rule of thumb, whenever one function calls another, the constness of a variable should *never* decrease. Over each function boundary, constness should always either stay the same, or increase. Caller Called normal normal = ok const const = ok normal const = ok const normal = problem The correct solution is either to make the Called function const, or to un-const the Caller. > The same applies to some parameters attributed as non null, and > explicitly called with NULL argument in several locations. How can a > cleaner figure what is the desired correction? Yeah, that's the same kind of issue. Well, you could force the issue: throw an exception whenever the pointer is NULL, and then watch to see who complains. :) > Blindly changing atributes attributes just to pass test looks to me > like a problem, not a solution. I agree. So I'm not blindly consting get_string() and hoping nothing breaks. Instead, I'm whining about it on RT and p2, and hoping the designers will say something useful. :) (Hopefully either: * "rip it all out, no vtable methods can have const invocants, and therefore, neither can any function that calls a vtable method." or * "vtable functions M and N have const invocants, so they aren't allowed to call anything which could modify the invocant." ... I'd be happy either way.) Mark P.S. I don't actually feel very strongly about consting... I just think broken consting is worse than no consting at all, and I don't like papering over things that could lead to weird bugs later on.
