# whats the difference?!?

## Recommended Posts

look at these functions:
inline float Vec3Dot(VECTOR3 v1, VECTOR3 v2)
{
return v1.x*v2.x + v1.y*v2.y + v1.z*v2.z;
}

and
inline float Vec3Dot(VECTOR3* v1, VECTOR3* v2)
{
return v1->x*v2->x + v1->y*v2->y + v1->z*v2->z;
}

is there any performace difference between then?!?

##### Share on other sites
The second one is faster, but I would use constant references instead of pointers:
inline float Vec3Dot(const VECTOR3& v1, const VECTOR3& v2){    return v1.x*v2.x + v1.y*v2.y + v1.z*v2.z;}

##### Share on other sites
Quote:
 Original post by xissburglook at these functions:inline float Vec3Dot(VECTOR3 v1, VECTOR3 v2){ return v1.x*v2.x + v1.y*v2.y + v1.z*v2.z;}andinline float Vec3Dot(VECTOR3* v1, VECTOR3* v2){ return v1->x*v2->x + v1->y*v2->y + v1->z*v2->z;}is there any performace difference between then?!?
The latter is probably better, but you should prefer:
inline float Vec3Dot(const VECTOR3& v1, const VECTOR3& v2){    return v1.x*v2.x + v1.y*v2.y + v1.z*v2.z;}
[Edit: hehe :) ]

##### Share on other sites
Quote:
 Original post by jykThe latter is probably better

Faster, yes, but not better. People have to use unnecessary stuff like &, which seems to make no sense. Also the function have many problems, for example the function doesn't check whether the pointers are equal to 0, the function isn't const-correct either.

Of course the reference version presented by Roboguy and jyk is the best way.

EDIT: Are you even using C++? Looking at the code it could very well be C (operator overloading not used, pointers instead of references). If you are using C then the reference version (using &) isn't legal.

##### Share on other sites
Quote:
Original post by CTar
Quote:
 Original post by jykThe latter is probably better

Faster, yes, but not better.
Sorry, you are right. What I actually meant was 'better in the context of the OP's question regarding performance', but I didn't make that clear. I should have just said 'faster'.

##### Share on other sites
its C++ and I have forgotten about using references as arguments in the functions...thx for replying man.

and, can you please explain me why?!?(if it is not too complex :)...why using 'const' makes it faster/better? and why using references also makes it faster/better?

##### Share on other sites
the first version involves the copy constructor.
the two VECTOR3 parameters are duplicated and placed on the stack before the function is called.

the second version doesn't involve the copy constructor.
only the adress of the two VECTOR3 parameters are placed on the stack before the function is called.

there's no need to make a copy of the parameters, then it's faster.

in the second version, the function works with the adress of the parameters, and then, it can modify them. after the function is executed, the parameters passed to the function can have diferent values than before the function call.
it's not the case in the first version where it works with a copy of the parameters. after the function is executed, the parameters will have the same values as before the execution.
adding const prevents the function to modify the parameters passed to it, even if they are passed by adress or by reference.

##### Share on other sites
Quote:
 Original post by xissburgits C++ and I have forgotten about using references as arguments in the functions...thx for replying man.and, can you please explain me why?!?(if it is not too complex :)...why using 'const' makes it faster/better? and why using references also makes it faster/better?

The first version passes its arguments by value, which means they are copied and the function only has access to these copies. I'm guessing VECTOR3 has three float fields x, y and z. Every float is 4 bytes long, so this would be 3*4*2=24 bytes copied in arguments.

The pointer and reference versions pass pointers; pointers being 4 bytes long, this amounts to 8 bytes. The function has access to the actual vector objects, hence any modifications made by the function can be observed after it has returned.

Using pointers is "bad" since they can be null, so in theory you're supposed to check that in the function. References are better since they work exactly the same (= just as fast), but have a nicer syntax and cannot be null.

The const does not make the code faster. It only helps you, the programmer, make less mistakes, since the "const" points out that the function will not be modifying its arguments. It's a form of documentation, it shows your intentions better.

However, the function is declared inline; although modern compilers tend to ignore that keyword AFAIK, I'm not sure what the exact effects would be if a compiler would indeed inline it.

##### Share on other sites
const = makes it safer because it ensures you don't modify the vectors
reference = makes it simpler because a reference isn't supposed to be 0 (unlike pointers)

##### Share on other sites
Quote:
 Original post by xissburgwhy using 'const' makes it faster/better?

Faster because: LIES!!! It's probably not faster, but there's a couple of optimizations your compiler can occasionally throw in when it can tell that something won't be changed (because it's const)

Better because: [18] Const correctness, C++ FAQ Lite

Quote:
 references faster/better

Faster because: Less typing, and since it's a bug to let a reference-to-null be constructed in the first place, you needn't assert() that your reference is not null (you should assert() that a pointer is not null before dereferencing it, however)

Better because: The function does not logically deal with memory - there is no new/delete/memory offset. Using pointers forces you to deal with memory, complexifying simple operations with asserts (!= null), reference (&) and dereference (*) operators, etc.

##### Share on other sites
Quote:
 Original post by xissburgis there any performace difference between then?!?

Try it out in your favourite compiler!!!

##### Share on other sites
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.

##### Share on other sites
Quote:
 Original post by Namethatnobodyelsetookconst 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.
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.

##### Share on other sites
Quote:
 Original post by Namethatnobodyelsetookconst 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

##### Share on other sites
Quote:
Original post by Anonymous Poster
Quote:
 Original post by Namethatnobodyelsetookconst 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.
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.

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.

##### Share on other sites
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.

##### Share on other sites
Quote:
Original post by SamLowry
Quote:
 Original post by Anonymous PosterNo, 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.
I also mentioned this.
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.

##### Share on other sites
Quote:
 Original Post by Eddycharlyadding 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...

##### Share on other sites
Quote:
 Original post by xissburgbut 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...
Constant 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):

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.

## Create an account

Register a new account

• ### Forum Statistics

• Total Topics
628392
• Total Posts
2982420

• 10
• 9
• 19
• 24
• 11