Quote:Original post by xissburg
is there any performace difference between then?!?
Try it out in your favourite compiler!!!
whats the difference?!?
Try it out in your favourite compiler!!!
const can make your app faster... If you were to access a member of a struct, call a function that took that struct as const, then access the struct again. When the function takes const parameters, or is a const member function, the compiler knows the struct cannot change during the function call. This allows the compiler to possibly optimize the second access to the structure, by just using the value read the first time.
Quote:Original post by NamethatnobodyelsetookNo, it can't. Because there's const_cast that takes away constness. And if the compiler is smart enough to see if you're using const_cast, then the compiler damn sure is smart enough to see if you're modifying the values. Know that const objects can also be passed to other functions which may use const_cast on them to cast away constness. So using "const" buys you nothing in terms of speed.
const can make your app faster... If you were to access a member of a struct, call a function that took that struct as const, then access the struct again. When the function takes const parameters, or is a const member function, the compiler knows the struct cannot change during the function call. This allows the compiler to possibly optimize the second access to the structure, by just using the value read the first time.
Quote:Original post by Namethatnobodyelsetook
const can make your app faster... If you were to access a member of a struct, call a function that took that struct as const, then access the struct again. When the function takes const parameters, or is a const member function, the compiler knows the struct cannot change during the function call. This allows the compiler to possibly optimize the second access to the structure, by just using the value read the first time.
Then again...
Σnigma
Quote:Original post by Anonymous PosterQuote:Original post by NamethatnobodyelsetookNo, it can't. Because there's const_cast that takes away constness. And if the compiler is smart enough to see if you're using const_cast, then the compiler damn sure is smart enough to see if you're modifying the values. Know that const objects can also be passed to other functions which may use const_cast on them to cast away constness. So using "const" buys you nothing in terms of speed.
const can make your app faster... If you were to access a member of a struct, call a function that took that struct as const, then access the struct again. When the function takes const parameters, or is a const member function, the compiler knows the struct cannot change during the function call. This allows the compiler to possibly optimize the second access to the structure, by just using the value read the first time.
Incorrect.
You're right about const not making any difference in performance, but the reason is that a compiler can easily find out by itself whether or not a function modifies its arguments or not (in the case of the dot product function), so even if you do not specify an argument as const, the compiler may still perform optimisations as if it were, as long as the argument isn't modified in any way.
In more general cases, const does not mean the value will not change.
VECTOR3 vec(1,1,1);void f(const VECTOR& v){ vec.x = vec.y = vec.z = 0;}void g(const VECTOR& v){ // v = (1,1,1) f(v); // v = (0,0,0)}int main(){ g(vec);}const_cast is an entirely different affair. It is an error to const_cast a const value and then modify it. The compiler does not have to take into account this possibility when considering optimisations. Const-casting and modifying leads to undefined behavior. The only reason const_cast exists is to make it possible to work with code that is not const-correct.
The first function will be faster if the compiler actually does inline the function. A particularly cunning compiler would transform them into the same machine code.
Quote:Original post by SamLowryI also mentioned this.Quote:Original post by Anonymous Poster
No, it can't. Because there's const_cast that takes away constness. And if the compiler is smart enough to see if you're using const_cast, then the compiler damn sure is smart enough to see if you're modifying the values. Know that const objects can also be passed to other functions which may use const_cast on them to cast away constness. So using "const" buys you nothing in terms of speed.
Incorrect.
You're right about const not making any difference in performance, but the reason is that a compiler can easily find out by itself whether or not a function modifies its arguments or not (in the case of the dot product function), so even if you do not specify an argument as const, the compiler may still perform optimisations as if it were, as long as the argument isn't modified in any way.
Quote:const_cast is an entirely different affair. It is an error to const_cast a const value and then modify it.I was thinking of pointers and references to const objects, which can be legally const_casted and modified.
Author
Quote:Original Post by Eddycharly
adding const prevents the function to modify the parameters passed to it, even if they are passed by adress or by reference.
but the Vec3Dot() function for example doesnt change the VECTOR3s passed as arguments!! so, why use it? is there a chance of occur an error and the VECTORs get chaged?!? dont understand why to use const sometimes...
Quote:Original post by xissburgConstant correctness is an important concept, and requires using the keyword consistently even when it doesn't seem that important. Here are some links that will explain it better than I can (just hits from google):
but the Vec3Dot() function for example doesnt change the VECTOR3s passed as arguments!! so, why use it? is there a chance of occur an error and the VECTORs get chaged?!? dont understand why to use const sometimes...
1...
2...
3...
There are many examples that can be made, but just consider that if the arguments to dot() are not constant, then dot() cannot be called on constant arguments to other functions. That means that no function that calls dot() on its arguments can itself have constant arguments. This sort of thing can propogate throughout your code until you've more or less lost the option of making anything constant. In that sense, constant correctness is kind of an 'all or nothing' proposition, and overall you're better off with it than without it.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement