const or not, function parameter difference

[evren320]

i understand concept of defining constant variables like

const int i = 5;
const char * tx = "hello";

but i don't understand when it comes to function parameters, what is the difference between these pairs

void func(int i){}
void func(const int i){}

int func(){}
const int func(){}

void func(char * tx){}
void func(const char * tx){}

char * func(){}
const char * func(){}

[JohnW@Wessex]

void func(int i){} // The function can modify the copy of 'i'
void func(const int i){} // The function can't modify the copy of 'i'. 

int func(){}
const int func(){} // No real difference as far as I can see.

void func(char * tx){} // The function can modify what what tx points to.
void func(const char * tx){} // The function can't modify what what tx points to.

char * func(){} // The pointer returned can be used to modify the value it points to.
const char * func(){}// The pointer returned can't be used to modify the value it points to.

There are others.

void func(int &i){} // The function can modify the original 'i'.
void func(const int &i){} // The function can't modify the original 'i'.

The above forms are useful for passing objects that have a high copy cost.

[originalfamousjohnsmith]

It means if you try to compile something and you change the object within the const call it will fail.

Const is a const pain as far as I am concerned. I've never once had it usefully detect an error, and it causes a lot of very tricky runtime errors and language issues, but you generally get forced into using it due to third party libs.

[JohnW@Wessex]

Const is a const pain as far as I am concerned.

By contrast, I apply const-correctness throughout my code.

[evren320]

const int i=5;
int i=5;

is const have more performance over regular variable?
if we write function with const parameter, is it have more performance too?
what is the benefit of const, if we don't have benefit, why such thing exist ?

[JohnW@Wessex]

const int i=5;
int i=5;

is const have more performance over regular variable?

Maybe, depends on the compiler. But it won't be less performance.

if we write function with const parameter, is it have more performance too?

Also maybe.

what is the benefit of const, if we don't have benefit, why such thing exist ?

The benefit of const is that it is a contract between parts of the code. It says "I consider it to be an error to change this variable and any code that tries should be flagged as such."

Example

class Test
{
public:
    void Function(const Object &object) const;
};

The member function says that it takes its parameter as a const reference, which means that it will not change the original.
The trailing const says that it promises that it will not change any of the members of Test.

Code can be written that relies on that contract.
If someone were to try to change the contents of 'Function' so that it breaks the contract, then it will be flagged as an error.

[evren320]

so it benefits when someone wants to use your code, or you are using someone's code.
except that, i wonder if no performance benefit? if someone already know answer, i would convert some of my variables to const to speed up, or maybe memory conservation

[monarch_dodra]

and it causes a lot of very tricky runtime errors

I have yet to see a const-related run-time error. Not even sure it is possible unless you use const-cast. But if you const cast const objects, you are doing something wrong.

[monarch_dodra]

so it benefits when someone wants to use your code, or you are using someone's code.
except that, i wonder if no performance benefit? if someone already know answer, i would convert some of my variables to const to speed up, or maybe memory conservation

There are some slight performance benefits, but nothing extraordinary.

To answer your question though, don't const your variables for speed benefits, but do it for const correctness.

Also, remember that YOU are usually the biggest user of your code. You will also benefit from const correctness yourself.

[kempofighter]

When writing a user interface it is a very important part of the documentation to specify const correctness. You need to make it clear to the users whether their inputs are safe from modification or not. When passing by value it doesn't make much difference since the function would be working on its own copy. When dealing with pointers and references it is critical to write const correct code. Users won't want to pass a non-const pointer to a function unless the function was designed to modify the data.

One run-time error that I can think of is this:

// name is non-const but it points to a const string literal!  It compiles
// but is very dangerous
char* name = "Steve Johnson";

// later someone tries to modify name but this will cause undefined 
// behavior.  name was written as a non-const pointer but it 
// points to a string literal.  therefore the code compiles and will
// allow you to attempt to change it.
strcpy(name, "Rick Johnson");

// It is important to write this instead.  Now the compiler will not 
// allow you to change it and you can avoid an annoying run-time
// error that trips up a lot of beginners!
const char* name = "Steve Johnson";

[Lindley]

I have yet to see a const-related run-time error. Not even sure it is possible unless you use const-cast. But if you const cast const objects, you are doing something wrong.

You can get unexpected runtime behavior if you do something like this:

const int i = 5;
int *ptr = (int*)&i;
*ptr = 6;

But that's a pathological case. For the most part, compilers are pretty smart about figuring out when they can or cannot guarantee that something really is constant. Usually they can't, due to aliasing, so in that case the benefit is solely in increased compile-time checking.

[monarch_dodra]

You can get unexpected runtime behavior if you do something like this:

const int i = 5;
int *ptr = (int*)&i;
*ptr = 6;

But that's a pathological case. For the most part, compilers are pretty smart about figuring out when they can or cannot guarantee that something really is constant. Usually they can't, due to aliasing, so in that case the benefit is solely in increased compile-time checking.

I agree, but if you ask me, that's a const_cast in disguise if I ever saw one XD

[Paul McKenzie]

Const is a const pain as far as I am concerned.

I guess you've never had to write a code library that others will use. The const is used for documentation purposes as well as to enforce that the parameter will not change.

By not being const correct, the user of a library will believe that what they're passing will be changed, so they have to jump through hoops making their code "safe" when there need not be.

For example:

void foo(std::string & arg1)
{
   // arg1 never gets changed.
}

Now the user sees that the argument is not const, so they have to do this:

void mycode()
{
   std::string x = "abc123";
   foo( x );
}

Instead of just this:

foo( "abc123" );

Regards,

Paul McKenzie

[JohnW@Wessex]

This is worth reading for anyone with questions about const-correctness

http://www.parashift.com/c++-faq-lit....html#faq-18.1