HOWTO: const and pointer variants in C and C++ : c++
This is a discussion on HOWTO: const and pointer variants in C and C++ within the c++ forums in Programming Languages category; blargg wrote: > pfiland@mindspring.com wrote: >> blargg wrote: >>> Care to show any examples of where const helps speed-wise? That is, a >>> program where removing const wouldn't change the semantics of the program, >>> but would reduce its speed. I'm not arguing against using const, just >>> questioning this often-made claim. >> const could help a compiler determine if a variable >> could be replaced with a constant in machine code. >> Opcodes with operands, usually have smaller faster >> versions which operate on constants. > [...] > > Yes, but can you provide EXAMPLES of where const actually ...
| c++ comp.lang.c++ usenet archive |
![]() |
| | LinkBack | Thread Tools |
|
#11
| |||
| |||
| > pfiland@mindspring.com wrote: >> blargg wrote: >>> Care to show any examples of where const helps speed-wise? That is, a >>> program where removing const wouldn't change the semantics of the program, >>> but would reduce its speed. I'm not arguing against using const, just >>> questioning this often-made claim. >> const could help a compiler determine if a variable >> could be replaced with a constant in machine code. >> Opcodes with operands, usually have smaller faster >> versions which operate on constants. > [...] > > Yes, but can you provide EXAMPLES of where const actually helps the > compiler determine this, where it couldn't determine it without const? 'const' in C++ has serves multiple purposes. It can 1) declare constness of an object itself, and 2) declare constness of an access path to an object, 3) serve as a distinguishing trait in overload resolution. How the third role can be used in "optimization" is rather obvious. But these are basically user optimizations, as opposed to complier optimizations. I assume that you are talking about compiler optimizations, to which the third role is not immediately relevant. I don't think I need to provide examples of how the first role of 'const' can speed up the code. They are immediately obvious as well. Constant values can be calculated at compile time. Code that depends on constant values can be reduced at compile time. Etc. The second role of 'const' is more about discipline, than about optimization. In general case, the constness of access path does not imply the constness of the object this access path leads to. Which means that in general case without preforming a thorough aliasing ****ysis, the compiler can't do much based on the constness of access path itself. And if the compiler is smart enough to perform a sufficiently thorough aliasing ****ysis, it should be smart enough to optimize it regardless of whether the explicit 'const' is supplied by the user or not. So, I'd agree that the second role of 'const' by itself is not immediately useful for compiler optimizations. However, it is worth noting that it might become quite useful if the user explicitly gives the compiler the permission to perform "overly agressive" optimizations (meaning, that they might be formally invalid in general case) by assuming some aliasing properties of the code, instead of trying to derive them from the code itself. (I'm not sure, but it is quite possible that the combination of 'const' with C99's 'restrict' allows for more valid straightforward optimizations that just a mere 'restrict'.) -- Best regards, Andrey Tarasevich |
|
#12
| |||
| |||
| Hendrik Schober wrote: > pete wrote: >> [...] >> I don't think that removing const >> ever changes the semantics of a program. > > struct test { > int f() {return 1;} > int f() const {return 0;} > }; > > int main() > { > /*const*/ test x; > return x.f(); > } In order to make a point, you would have to post a correct c program which contains the const keyword, and which also does something different when const is removed. -- pete |
|
#13
| |||
| |||
| Hendrik Schober wrote: > pete wrote: >> [...] >> I don't think that removing const >> ever changes the semantics of a program. > > struct test { > int f() {return 1;} > int f() const {return 0;} > }; > > int main() > { > /*const*/ test x; > return x.f(); > } In order to make a point, you would have to post a correct c program which contains the const keyword, and which also does something different when const is removed. -- pete |
|
#14
| |||
| |||
| blargg wrote: > pfiland@mindspring.com wrote: >> blargg wrote: >>> Care to show any examples of where const helps speed-wise? That is, a >>> program where removing const wouldn't change the semantics of the program, >>> but would reduce its speed. I'm not arguing against using const, just >>> questioning this often-made claim. >> const could help a compiler determine if a variable >> could be replaced with a constant in machine code. >> Opcodes with operands, usually have smaller faster >> versions which operate on constants. > [...] > > Yes, but can you provide EXAMPLES of where const actually helps the > compiler determine this, where it couldn't determine it without const? No, I can't really. -- pete |
|
#15
| |||
| |||
| blargg wrote: > pfiland@mindspring.com wrote: >> blargg wrote: >>> Care to show any examples of where const helps speed-wise? That is, a >>> program where removing const wouldn't change the semantics of the program, >>> but would reduce its speed. I'm not arguing against using const, just >>> questioning this often-made claim. >> const could help a compiler determine if a variable >> could be replaced with a constant in machine code. >> Opcodes with operands, usually have smaller faster >> versions which operate on constants. > [...] > > Yes, but can you provide EXAMPLES of where const actually helps the > compiler determine this, where it couldn't determine it without const? No, I can't really. -- pete |
|
#16
| |||
| |||
| pete wrote: > Hendrik Schober wrote: >> pete wrote: >>> [...] >>> I don't think that removing const >>> ever changes the semantics of a program. >> >> struct test { >> int f() {return 1;} >> int f() const {return 0;} >> }; >> >> int main() >> { >> /*const*/ test x; >> return x.f(); >> } > > In order to make a point, > you would have to post a correct c program In case you haven't noticed, this message is cross-posted to two groups where C++ code is entirely appropriate; the Subject: line might also be a hint. > which contains the const keyword, > and which also does something different when const is removed. The above program does something quite different when the comment markers are removed from around the second 'const'. |
|
#17
| |||
| |||
| pete wrote: > Hendrik Schober wrote: >> pete wrote: >>> [...] >>> I don't think that removing const >>> ever changes the semantics of a program. >> >> struct test { >> int f() {return 1;} >> int f() const {return 0;} >> }; >> >> int main() >> { >> /*const*/ test x; >> return x.f(); >> } > > In order to make a point, > you would have to post a correct c program In case you haven't noticed, this message is cross-posted to two groups where C++ code is entirely appropriate; the Subject: line might also be a hint. > which contains the const keyword, > and which also does something different when const is removed. The above program does something quite different when the comment markers are removed from around the second 'const'. |
|
#18
| |||
| |||
| Hendrik Schober wrote, On 11/11/08 15:41: > pete wrote: >> [...] >> I don't think that removing const >> ever changes the semantics of a program. > > struct test { > int f() {return 1;} > int f() const {return 0;} > }; This is not valid C and is an example of why cross-posting between C and C++ groups is generally a bad idea. Please keep answers which are specifically C++ in groups where C++ is topical. -- Flash Gordon If spamming me sent it to smap@spam.causeway.com If emailing me use my reply-to address See the comp.lang.c Wiki hosted by me at http://clc-wiki.net/ |
|
#19
| |||
| |||
| Hendrik Schober wrote, On 11/11/08 15:41: > pete wrote: >> [...] >> I don't think that removing const >> ever changes the semantics of a program. > > struct test { > int f() {return 1;} > int f() const {return 0;} > }; This is not valid C and is an example of why cross-posting between C and C++ groups is generally a bad idea. Please keep answers which are specifically C++ in groups where C++ is topical. -- Flash Gordon If spamming me sent it to smap@spam.causeway.com If emailing me use my reply-to address See the comp.lang.c Wiki hosted by me at http://clc-wiki.net/ |
|
#20
| |||
| |||
| James Kuyper wrote, On 11/11/08 19:12: > pete wrote: <snip> >> In order to make a point, >> you would have to post a correct c program > > In case you haven't noticed, this message is cross-posted to two groups > where C++ code is entirely appropriate; the Subject: line might also be > a hint. It is also posted to a group where C++ is NOT topical. The way pete indicated this might not be the best, but it is certainly true that the example given was not correct for comp.lang.c where only C is topical. Is it really too difficult for people with C++ specific answers to drop the cross-post to comp.lang.c? -- Flash Gordon If spamming me sent it to smap@spam.causeway.com If emailing me use my reply-to address See the comp.lang.c Wiki hosted by me at http://clc-wiki.net/ |



