Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

For me it's the other way around -- I use const for global variables because it makes a real difference, the data will be put in a .ro section.

Pointer-to-const on the other hand (as in "const Foo *x") is a bit of a fluff and it spreads like cancer. I agree with the author that const is a waste of time. And it breaks in situations like showcased by strstr().

I use pointer-to-const in function parameter lists though (most of the time it does not actually break like in strstr()): as documentation, and to be compatible with code that zealously attaches const everywhere where there (currently) is no need to mutate.

But overall my use of const is very very little and I generally do not waste my time (anymore) with it. I almost never have to use "const casts" so I suppose I can manage to keep it in check. In C++ it is a bit worse, when implementing interfaces, like const_iterator etc. That requires annotating constness much more religiously, and that can lead to quite a bit of cruft and repetition.



You're right, I also mark array definitions as const to control the section they go in, I was thinking about things like const int a = 5; ... anything I want a simple const var for is done with #define for me.

const is indeed viral when eg, used in apis, but it's a strong indication at a glance for api users what they can expect to happen to the memory the pointer points to, whether it's just for input or is modified... and the virality is only a pain (it can be a pain) if you didn't use it from the start so all the things it might call are already kitted out with it.


const makes sense and rarely causes problems when used in function parameter lists.

However, when used for members in datastructures, it's more often than not problematic.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: