begin quoting Christopher Smith as of Sun, Oct 01, 2006 at 03:22:49PM -0700:
> James G. Sack (jim) wrote:
> > Stewart Stremler wrote:
> >> ..
> >> My problem with const almost always comes down to not using it
> >> consistently,
>
> Hehe. Yeah, POSIX and Win32 interfaces were generally defined prior to
> widespread use of "const". To a large degree people have gone back and
> fixed these declarations, but there is nonetheless a lot of old code.
There's a break in habits required when shifting from old code to
new code as well.
> That said, so long as you really believe that a function will honor a
> "const" contract, there is little harm in casting away const when you
> call the function.
I work with people who would flag such a thing as a "major bug"... :-/
(And I'm not sure I disagree. If the compiler complains, fix the code!)
> >> and then starting from the wrong side ("Oh, I think I'll make this a
> >> const. Whoops, that function doesn't take const, but now it needs
> >> to. Whoops, it passes that value on to a function that doesn't use
> >> const either!"). And when one is done inserting "const" in all the places
> >> that should have "const" in 'em.... the code has been uglified. Bleah.
>
> Generally, I've found these scenarios tend to be pretty illuminating
> experiences actually, as they typically lead to discovering that the
> const contract isn't being held somewhere you thought it was.
Doesn't make it less painful or prettier, alas.
[snip]
> > I personally, never felt too much urge to declare my (er..) variables as
> > const. Does that happen a lot?
> >
> I guess it depends. I find it useful to have const member variables. It
> also tends to be nicer to define constants using const instead of the
> evil #define.
Heh.
I only find #define evil if it actually *does* something; while real
constants are nice, they tend to get put in while the fifteen-line
complicated #define macro is left in. That's slightly backwards.
(I probably would've preferred a real keyword for constants -- say,
"constant" -- and a *different* keyword to indicate that some object
shouldn't be on the left-hand-side of an assignment.)
> For variables within a function, const mostly helps with
> readibility, as someone who is reading the code for the first time and
> seeing some kind of problem towards the end of a function, they can see
> that it is declared const at the beginning and skip over most of the
> intervening code.
Unless, of course, the language being used magically un-consts a
const...
> Note that one other aspect of const is that it makes the optimizer's job
> easier/possible, particularly during the compilation phase or if you are
> using dynamic linking/shared libraries.
Isn't that what volatile is for? "You can't optimize this access, but
everything else is fair game." The compiler already has logic to
determine that a variable won't change in the scope of current
execution.
--
_ |\_
\|
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
