Sign in to follow this  

Function( const int value )

This topic is 4667 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

This is a really generic question. Why specify const for a value that isn't a pointer or reference? Is there a reason? I'm only thinking there might be because the compiler lets me do it. When you pass something to a function, it copies it. So what's the point of it being const? Unless maybe you just didn't trust yourself to not touch a parameter's value. Just curious. Thanks for any details.

Share this post


Link to post
Share on other sites
No real reason for this. Passing as const really dosen't change anything about the parameter. I sometimes like to declare char* parameters as const char* parameters just for consistancy.

Share this post


Link to post
Share on other sites
As Stompy9999 said, there isn't really a reason.

Quote:
Original post by Stompy9999
I sometimes like to declare char* parameters as const char* parameters just for consistancy.
Actually, you should always pass as const char* where you can. E.g. this should result in a compile error:

void Log(char* sz)
{
printf("%s\n",sz);
}

Log("Hello World!"); // Error, cannot convert from const char* to char*

Share this post


Link to post
Share on other sites
IIRC; C++ allows the 'magical' conversion of nameless temporaries from constness to non-constness. Somehow, string literals fall into this catagory. AFAIK C allows this for string literals as well; or atleast it used to.

Anyway; constness on a parameter is generally pointless unless the parameter is a reference or a pointer. But it doesn't hurt.

Share this post


Link to post
Share on other sites
Const is one of those keywords that equates to painfully removing a band-aid in one quick swoop rather then gradually pulling the band-aid off over a 10 minute period. Its up front, it gets it out of the way, you can get on with your life.

By using the const keyword along side all of the parameters, you assure yourself that if you change the value of a parameter, it'll be a compiler error, rather then a logic bug which could prove very very annoying at a later time. So, idealistically you should use it as much as you possibly can.

Share this post


Link to post
Share on other sites
[edit] Blah...beat by Inmate2993 [lol] Type faster fingers! [/edit]
Well there's some more to it as well. Because it let's you modify a parameter, you might not always want that. For example:

int Test(const int i)
{
i++;
}


Generates an error while

int Test(int i)
{
i++;
}
Does not. That seems trivial now, but when you are working with a larger project, this is all to possible to sneak up on you:
 
int Test(int x, int y, int z)
{
.. Lots of code ...
for( int x = 0; x < 5; x++ )
access x - but which one?
...
.. Lots of more code ...
}
Since programmers go for the most convient name use, it is possible that you may accidently reuse a parameter and not even know it. If you const'd it, that would not happen.

I usually never use const. Just my own preference though, but you should hopefully be able see some of its usefullness.

- Drew

Share this post


Link to post
Share on other sites
Const is just another a way of telling the compiler "I will never change the data I give to you".I usually do not use it,but const correctness has saved a lot of people.

Share this post


Link to post
Share on other sites
Quote:
Since programmers go for the most convient name use, it is possible that you may accidently reuse a parameter and not even know it. If you const'd it, that would not happen.


Const does not effect name hiding. In your example, wether the parameter is const or not, reffering to x inside the for loop always refers to the x declared in that for loop.

Incidentally, I always make all parameters const, and remove the const if I have to modify it.

Share this post


Link to post
Share on other sites
Quote:
Original post by Deyja
Const does not effect name hiding. In your example, wether the parameter is const or not, reffering to x inside the for loop always refers to the x declared in that for loop.


Oh, much agreed! However, what I was hinting at is when you declare a local variable in a function and happen to have a parameter that is the same. The same goes for if you are in some class member function and declare a local variable name with the same name as a class member. Unless you explicitly tell it what to use, you are in a world of headaches when debugging.

Share this post


Link to post
Share on other sites
Quote:
Original post by Deyja
Quote:
Since programmers go for the most convient name use, it is possible that you may accidently reuse a parameter and not even know it. If you const'd it, that would not happen.


Const does not effect name hiding. In your example, wether the parameter is const or not, reffering to x inside the for loop always refers to the x declared in that for loop.
True, but what Drew was pointing at was that you might accidently modify the varible, and then use it further down in the code. In his example, what happens if you rename the loop counter to 'z' instead of 'x', but leave the code in the loop referencing x? If it's const, you'll get a compile error. Otherwise, you'll get a bug in your code that could be hard to spot.

Share this post


Link to post
Share on other sites
This is just off the top of my head.
Suppose you have two function definitions:

void f(const int x) {...}
void f(int g) {...}

and then the following piece of code:

a = 1;
f(a);
g(a);
f(a);

This could translate to machine code as follows (I'm assuming C calling convention, __stdcall won't work -- nor __fastcall, because eax is not guaranteed to remain unchanged across function calls):

push 1
call _f
call _g
mov dword [esp], 1
call _f

So, the compiler could choose not to push "a" on the stack a second time when calling "g()", reusing the previous value, because the stack value is marked as "const".
Of course this is risky (a.k.a. I don't think will ever happen) in the world of C/C++ where you can discard that const with a simple typecast (with gcc you don't need a cast, you'll get just a warning that you're assigning to a const location), so I doubt there's any C/C++ compiler that outputs that code; maybe if const was really enforced... (maybe this works with "final" in java, hmm...)
Anyway, I was just looking for an excuse for pass-by-value consts... ignore me :P

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
So no magical use of it, huh?

Quote:
Original post by hothead
I usually do not use it,but const correctness has saved a lot of people.

[lol]

Quote:
Original post by Drew_Benton
..trivial now, but when you are working with a larger project, this is all to possible to sneak up on you:

I'm not so sure the size of the project really matters as much as the size of the function. I actually modify function parameters in the function quite a lot. I mean why not, it's a copy of the variable being created for the function..

inline FLOAT ShiftTowards(FLOAT current, FLOAT goal, FLOAT speed)
{
if( goal != current )
{
if(goal goal)
current = goal;
}
}

return current;
}
Why declare another variable on the stack? current is what is changing, so why not really change it? The function caller may also want to store the changed value into a different location, so passing a non-const ref or ptr wouldn't be as flexible.

The biggest problem I have is all of the typing and code space wasted, heh. Pointers or references declared as const make sense, because you're showing the function caller that the data won't be changed. With non-refs, the const keyword would at most provide protection for the function writer from themself. I'm all for protecting myself from myself, but within such a small scope, it's kind of excessive. Unless you write gigantic, confusing functions.

Thanks for the info [smile]

Share this post


Link to post
Share on other sites
Oops, that was me. That chopped up code was supposed to look like this:
inline FLOAT ShiftTowards(FLOAT current, FLOAT goal, FLOAT speed)
{
if( goal != current )
{
if(goal < current)
{
current -= speed;
if(current < goal)
current = goal;
}
else
{
current += speed;
if(current > goal)
current = goal;
}
}

return current;
}

Share this post


Link to post
Share on other sites

This topic is 4667 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this