Comments on: "const" Keyword Explained http://www.safercode.com/blog/2009/02/04/const-keyword-explained.html Making Your Code Faster, Stronger, Safer… Tue, 31 Aug 2010 16:47:37 +0000 http://wordpress.org/?v=2.9.1 hourly 1 By: Umesh Patel http://www.safercode.com/blog/2009/02/04/const-keyword-explained.html#comment-3489 Umesh Patel Wed, 17 Feb 2010 11:28:14 +0000 http://www.safercode.com/blog/2009/02/04/const-keyword-explained.html#comment-3489 Does any one know How const objects are imlemented in compiler? Does any one know How const objects are imlemented in compiler?

]]> By: sreekanth http://www.safercode.com/blog/2009/02/04/const-keyword-explained.html#comment-264 sreekanth Thu, 05 Mar 2009 09:51:49 +0000 http://www.safercode.com/blog/2009/02/04/const-keyword-explained.html#comment-264 nice indepth knownledge nice indepth knownledge

]]> By: Volatile: C Keyword Myths Dispelled | Safer Code - Secure Coding In C C++ And More.. http://www.safercode.com/blog/2009/02/04/const-keyword-explained.html#comment-195 Volatile: C Keyword Myths Dispelled | Safer Code - Secure Coding In C C++ And More.. Tue, 24 Feb 2009 14:06:27 +0000 http://www.safercode.com/blog/2009/02/04/const-keyword-explained.html#comment-195 [...] time we explained the real meaning of const keyword, this time it’s going to be Volatile, the other sibling of this most misunderstood duo in C [...] [...] time we explained the real meaning of const keyword, this time it’s going to be Volatile, the other sibling of this most misunderstood duo in C [...]

]]> By: Shantanu Goel http://www.safercode.com/blog/2009/02/04/const-keyword-explained.html#comment-138 Shantanu Goel Tue, 10 Feb 2009 14:12:13 +0000 http://www.safercode.com/blog/2009/02/04/const-keyword-explained.html#comment-138 @Ric: oops, what a blunder :) ..fixed..thanks.. @Ric: oops, what a blunder :) ..fixed..thanks..

]]> By: Ric http://www.safercode.com/blog/2009/02/04/const-keyword-explained.html#comment-137 Ric Tue, 10 Feb 2009 13:10:22 +0000 http://www.safercode.com/blog/2009/02/04/const-keyword-explained.html#comment-137 int main() is missing a return statement, or maybe I'm just old fashioned int main() is missing a return statement, or maybe I’m just old fashioned

]]> By: Anonymous http://www.safercode.com/blog/2009/02/04/const-keyword-explained.html#comment-135 Anonymous Tue, 10 Feb 2009 10:11:02 +0000 http://www.safercode.com/blog/2009/02/04/const-keyword-explained.html#comment-135 the const keyword does not, even i the c++ standard, mean that this is not modifiably though that name const is mutable. Please red the C++ faq lite. It has a long, and correct, description of const. http://www.parashift.com/c++-faq-lite/const-correctness.html the const keyword does not, even i the c++ standard, mean that this is not modifiably though that name const is mutable.

Please red the C++ faq lite. It has a long, and correct, description of const.

http://www.parashift.com/c++-faq-lite/const-correctness.html

]]> By: norbert http://www.safercode.com/blog/2009/02/04/const-keyword-explained.html#comment-132 norbert Mon, 09 Feb 2009 19:19:54 +0000 http://www.safercode.com/blog/2009/02/04/const-keyword-explained.html#comment-132 sorry for the post above, I flumbled and sent it too early foo_resize_tag_array could do all kind of thing to foo, including modfying the content pointed by tag, which was return by foo_look_for_tag() and could very well be a reference to some part of a buffer under foo. this would not raise a compiler error nor warning, and the writter of foo_intern_tag() could have very honnestly claimed that tag is const, as far as his use of it goes. const 'may' use the compiler, and the compiler is much better than human to detect these gatchas. A programming trusting const is looking for trouble. Furthermore, many time prototypes are not const correct due to legacy isssues (the code had at one point to be compiled with K&R compiler which did not support const, and nobody revisited the code to add the conditional to allow double-compile... especially since it IS a perforamce issue, and most of the code is not performance critical. I personally tend to use const for low-level functions that I can guarantee will not have any side-effet (as illustrated above). And it is true that most of the time it has no performance impact, because most of the time the compiler can determine the cosnt status by itself (or canot rely on it). Still on the few case where it can, it is a free lunch. And I'm banking on the evolution of the compiler and the standard that will make const be more and more useful (think anti-aliasing and other effort to allow the optimizer to do its job) sorry for the post above, I flumbled and sent it too early

foo_resize_tag_array could do all kind of thing to foo, including modfying the content pointed by tag, which was return by foo_look_for_tag() and could very well be a reference to some part of a buffer under foo.

this would not raise a compiler error nor warning, and the writter of foo_intern_tag() could have very honnestly claimed that tag is const, as far as his use of it goes.

const ‘may’ use the compiler, and the compiler is much better than human to detect these gatchas. A programming trusting const is looking for trouble.

Furthermore, many time prototypes are not const correct due to legacy isssues (the code had at one point to be compiled with K&R compiler which did not support const, and nobody revisited the code to add the conditional to allow double-compile… especially since it IS a perforamce issue, and most of the code is not performance critical.

I personally tend to use const for low-level functions that I can guarantee will not have any side-effet (as illustrated above). And it is true that most of the time it has no performance impact, because most of the time the compiler can determine the cosnt status by itself (or canot rely on it). Still on the few case where it can, it is a free lunch. And I’m banking on the evolution of the compiler and the standard that will make const be more and more useful (think anti-aliasing and other effort to allow the optimizer to do its job)

]]> By: norbert http://www.safercode.com/blog/2009/02/04/const-keyword-explained.html#comment-131 norbert Mon, 09 Feb 2009 19:06:35 +0000 http://www.safercode.com/blog/2009/02/04/const-keyword-explained.html#comment-131 [Well, not unknowingly - that *should* cause a compiler error. (I’m pretty sure that’s in the spec) Of course, he may explicitly cast away const, but then we revert to my statement above.] Not necesseraly: look at: int a(....) { struct foo* foo char* tag; tag = foo_look_for_tag(foo) rc = foo_intern_tag(foo, tag); ... } foo_intern_tag(struct foo* foo, cosnt char* tag) { foo_resize_tag_array(foo, 1); } [Well, not unknowingly - that *should* cause a compiler error. (I’m pretty sure that’s in the spec) Of course, he may explicitly cast away const, but then we revert to my statement above.]

Not necesseraly: look at:

int a(….)
{
struct foo* foo
char* tag;

tag = foo_look_for_tag(foo)

rc = foo_intern_tag(foo, tag);
…
}

foo_intern_tag(struct foo* foo, cosnt char* tag)
{

foo_resize_tag_array(foo, 1);

}

]]> By: Smitty http://www.safercode.com/blog/2009/02/04/const-keyword-explained.html#comment-126 Smitty Mon, 09 Feb 2009 11:48:14 +0000 http://www.safercode.com/blog/2009/02/04/const-keyword-explained.html#comment-126 [The user cannot assume that the buffer he passed to func won’t be changed] Well, that's the 'promise' the author of the function is making by using the const modifier. Of course, he may renege on that promise, as I've stated before, but if he does he's foolish. He should either not declare the parameter as const, or not throw the const away. [It can easily be if the func implementer decides to (knowingly or unknowingly) take another pointer, point it to buf and then alter away the contents to his self-contentness..] Well, not unknowingly - that *should* cause a compiler error. (I'm pretty sure that's in the spec) Of course, he may explicitly cast away const, but then we revert to my statement above. [Whether a compiler will optimize or not with const, depends totally on the compiler because the spec doesn’t say anything about it.] Yes, that's my understanding as well, I would never advocate using const for performance, in fact, that's been my stance from my very first post. Norbert disagrees, and thinks const is all about compiler optimization. [The user cannot assume that the buffer he passed to func won’t be changed]
Well, that’s the ‘promise’ the author of the function is making by using the const modifier. Of course, he may renege on that promise, as I’ve stated before, but if he does he’s foolish. He should either not declare the parameter as const, or not throw the const away.

[It can easily be if the func implementer decides to (knowingly or unknowingly) take another pointer, point it to buf and then alter away the contents to his self-contentness..]
Well, not unknowingly – that *should* cause a compiler error. (I’m pretty sure that’s in the spec) Of course, he may explicitly cast away const, but then we revert to my statement above.

[Whether a compiler will optimize or not with const, depends totally on the compiler because the spec doesn’t say anything about it.]
Yes, that’s my understanding as well, I would never advocate using const for performance, in fact, that’s been my stance from my very first post. Norbert disagrees, and thinks const is all about compiler optimization.

]]> By: Shantanu Goel http://www.safercode.com/blog/2009/02/04/const-keyword-explained.html#comment-122 Shantanu Goel Sun, 08 Feb 2009 14:06:33 +0000 http://www.safercode.com/blog/2009/02/04/const-keyword-explained.html#comment-122 @Smitty: The user cannot assume that the buffer he passed to func won't be changed. It can easily be if the func implementer decides to (knowingly or unknowingly) take another pointer, point it to buf and then alter away the contents to his self-contentness.. Whether a compiler will optimize or not with const, depends totally on the compiler because the spec doesn't say anything about it. For example, if you were to pick up one of the guides for TI CCS (Optimizing Compiler Users' Guide - SPRU198) you can see in how many ways they use const to generate optimized code. @Smitty: The user cannot assume that the buffer he passed to func won’t be changed. It can easily be if the func implementer decides to (knowingly or unknowingly) take another pointer, point it to buf and then alter away the contents to his self-contentness..
Whether a compiler will optimize or not with const, depends totally on the compiler because the spec doesn’t say anything about it. For example, if you were to pick up one of the guides for TI CCS (Optimizing Compiler Users’ Guide – SPRU198) you can see in how many ways they use const to generate optimized code.

]]>