Christopher Smith wrote:
> 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.
> 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.
>>> 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. Of course,
> failure to use const whenever that contract is implied does create some
> problems, but the problem isn't too different from someone using "void*"
> when they should be using "char*".
>> I think that const is kinda neat in function declarations
>> char *strcpy(char *dest, const char *src);
>>
> I couldn't agree more. It makes it really easy to catch that case where
> you got src and dest order mixed up.
>> 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. 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.
>
> 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.
>
Well, there's enum, but I suppose it doesn't always fit the need as well
as a specific-typed variable.
I wonder if compiler optimized use of const objects ever gets broken by
one of those weird casts?
Or maybe those casts only work sometimes?
Regards,
..jim
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
