Function overloading....with const as one of the argument

My question is that can i overload function in c++ on the basis of declaring one argument as with const (constant).........

Eg..

Code:

---

int foo(int a)
{
 bla bla....
}

---

and

Code:

---

int foo(const int a)
{
bla bla....
}

---

are these two function same................i did it but got error....

Function Overloading this link say function overloading can be done with const ....YES is given there

> are these two function same................i did it but got error....
Posting actual code and actual error messages would help.

All you're going to get is "works for me" posts.

Code:

---

$ cat m1.cpp
#include <iostream>
using namespace std;

void foo ( const int *a ) {
  cout << "const " << *a << endl;
}
void foo ( int *a ) {
  cout << "var " << *a << endl;
}

int main ( ) {
  const int a = 1;
  int b = 2;
  foo(&a);
  foo(&b);
}
$ g++ m1.cpp
$ ./a.out
const 1
var 2

---

See - works for me!

You've left out "int" from your second function, but it wouldn't work even if you put it in. The reason is that there is no essential difference between those two. It's basically useless to declare an int parameter as const since it's just getting a copy of the value anyway. const is a guarantee to the caller that it's data won't be modified when it's passed by reference or pointer.

So the way to overload on const is like this:

Code:

---

int foo(int *a) {  // or int &a
    //...
}

int foo(const int *a) { // or const int &a
    //...
}

---

i used "*" pointer and it worked ...with const

Code:

---

int fun(int b)
{
    //..........
}

---

Code:

---

int fun(const int* b)
{
  //............
}

---

can u pls tell me IN DETAIL why..now these two function become different......

Your example is getting more stupid. Now you have one that's an int and one that's a (const) POINTER to an int, so obviously they are very different. You ask for "DETAIL" from us, but you yourself are being very sloppy. Re-read the examples above. I suspect that's all you're gettin'.

OK...... Watch this:
C++ - 30 - Function Overloading

Quote:

---

Originally Posted by Rohit Kumar

i used "*" pointer and it worked ...with const

Code:

---

int fun(int b)
{
    //..........
}

---

Code:

---

int fun(const int* b)
{
  //............
}

---

can u pls tell me IN DETAIL why..now these two function become different......

---

For some real 'fun', try calling that with zero!

Quote:

---

Originally Posted by iMalc

For some real 'fun', try calling that with zero!

---

Or NULL - same thing. To fix that, you should use nullptr if you have a C++11 compiler.

I'm no expert on the overloading/conversion/promotion riles, but I believe the real reason you can't overload int and const int the way you did is because a number (without postfixes), such as as 5, is pretty much a const int (because it's an int and you can't assign to a number).

Now, that int can be passed to the int overload (because a copy is made, the compiler won't break constness). But it can also be passed to const int, because again, the same logic applies. Either way, a copy is made, so the compiler cannot decide which function to call.

In Salem's example, it works because with a const int*, it cannot call the int* function, because that would allow the function to be able to modify the original value, hence breaking the const promise. That leaves only one overload, and that is the one it picks.

Quote:

---

Originally Posted by C++11 draft standard

Parameter declarations that differ only in the presence or absence of const and/or volatile are equivalent. That is, the const and volatile type-specifiers for each parameter type are ignored when determining which function is being declared, defined, or called. [
Example:

Code:

---

typedef const int cInt;
int f (int);
int f (const int); // redeclaration of f(int)
int f (int) { /* ... */ } // definition of f(int)
int f (cInt) { /* ... */ } // error: redefinition of f(int)

---

—end example
]
Only the const and volatile type-specifiers at the outermost level of the parameter type specification are ignored in this fashion; const and volatile type-specifiers buried within a parameter type specification are significant and can be used to distinguish overloaded function declarations.

In particular, for any type T, “pointer to T,” “pointer to const T ,” and “pointer to volatile T ” are considered distinct parameter types, as are “reference to T ,” “reference to const T ,” and “reference to volatile T

---

I don't really understand it either. I understand that foo(5) would be ambiguous, but how about

Code:

---

void foo(const int i)
{
  i++; // illegal
}
void foo(int i)
{
  i++; //legal
}

void caller(void)
{
  const int i1;
  int i2;
  foo(i2);
}

---

Much like you'd call a function overloaded with other potentially ambiguous types, like different sized integral types. Still, the standard has spoken, and I can't really think of a good reason to want to do this.

Well, essentially it says that any const and volatile specifiers that are not part of a pointer or reference type are ignored, so

void foo(int);
void foo(const int);
void foo(volatile int);
void foo(const volatile int);

are all considered equivalent. But if you add a pointer or reference type, the const or volatile becomes significant (i.e. not ignored), so

void foo(int*)
void foo(const int*)
void foo(int&)
void foo(const int&)

are all different signatures.

And so these are considered equivalent too:

void foo(int * const)
void foo(int * )

(same with & instead of *; or volatile (or const volatile) instead of const)

Basically, if it doesn't make a difference to the caller, it's equivalent.

You can't overload based on const-ness when it's pass-by value, because that const only says something about the copy, not the original.

Plus, using const while passing by value should be avoided anyway.

Quote:

---

Plus, using const while passing by value should be avoided anyway.

---

O_o

Nonsense.

One may avoid it if they desire, but if one desires the "firewall" of the compiler preventing one from accidentally mutating a variable, the approach is fine.

Soma

A gotcha with top level const variables, including parameters, is that if the type is movable, then making it top-level-const prevents it from being moved. This mostly creates an inefficiency error when returning such a variable by value. This is particularly relevant when there are multiple return statements in the function that return different variables, because RVO tends to fail in those cases. It can also create the same problem when you explicitly move the variable, but in that case the error is more obvious.

So that's a reasonable C++11 reason to avoid them.

Quote:

---

Originally Posted by oogabooga

And so these are considered equivalent too:

void foo(int * const)
void foo(int * )

(same with & instead of *; or volatile (or const volatile) instead of const)

Basically, if it doesn't make a difference to the caller, it's equivalent.

---

Except you can't have a "T & const". Based on a quick compiler experiment, it seems the attempt to do so will discard the const if it is created as the result of a typedef or similar, and error out if expressed directly.

Quote:

---

Originally Posted by King Mir

Except you can't have a "T & const".

---

Good point. I didn't think that through. It doesn't make sense to say int & const x, since you can't make x "point" to a different object with or without the const. Since references must be initialized and cannot be reassigned, they are essentially const (in that sense) already.

That reasoning would make sense with const, but volitile is dropped the same way. The real story is that there are rules which fold cv-qualified reference into actual unqualified references. It may, however, explain the C++ committee's rational for this.

Since a reference is (in a sense) just another name for an object, it perhaps doesn't make sense for the reference itself to be volatile, but only for the object to be.

Yet this is allowed:

Code:

---

typedef int & T;
void foo (volatile T ref_to_non_volatile){
}

---

And then there's this case:

Code:

---

typedef int & T;
void foo (volatile T & same_type_as_above){
}

---

A more common case where these rules are needed is when T is a template specified type.

Code:

---

// But this
typedef int & T;
void foo(volatile T x) { }

// is actually this
void foo(volatile int & x) { }

// not this
void foo(int & volatile x) { }

---

So, unless I'm missing something, your example is a reference to a volatile int, not a reference to a non-volatile.

Quote:

---

Yet this is allowed:

---

O_o

Not in the way you are suggestion as in response to oogabooga or his comments.

In both of those cases, `T' is treated as being simply `int &' type; in every way, the reference itself isn't `volatile'.

Furthermore, some compilers will allow it without warning; some compilers will allow it always producing a warning; some compilers will not allow it showing an error.

The problems related to producing a potentially "cv-modified" reference or "reference to a reference" is actually why you need "meta-functions" such as `add_const', `add_volatile', `remove_const', `remove_volatile', `add_reference', and `remove_reference'.

For example, the second bit of code fails under several versions of "MSVC", "BCC", and "ECC". (The error relates to "reference to reference is illegal" in general.) To further complicate the issue, the nature or the error depends on how `T' is formed. (In other words, a `T' formed from explicit template, inherited template, or standard traits all chance the error text.) You also have weird issues with overloading errors on some compilers.

Soma

Quote:

---

Code:

---

// But this
typedef int & T;
void foo(volatile T x) { }

// is actually this
void foo(volatile int & x) { }

// not this
void foo(int & volatile x) { }

---

---

O_o

I was afraid of that.

*sigh*

I didn't get here in time.

Code:

---

// But this
typedef int & T;
void foo(volatile T x) { }

// is actually this
void foo(int & x) { }

---

(Note: This code segment should actually always produce an error because the same function is being defined twice.)

That is, of course, when compilers allow the construct without error.

Code:

---

// this
void foo(int & x) { }
// is a different beast thant
void foo(volatile int & x) { }

---

Where these will actually overload, the resolution depends on the "volatility" of the underlying object.

Code:

---

    int f1;
    foo(f1);
    volatile int f2;
    foo(f2);

---

Soma

Quote:

---

Originally Posted by oogabooga

Code:

---

// But this
typedef int & T;
void foo(volatile T x) { }

// is actually this
void foo(volatile int & x) { }

// not this
void foo(int & volatile x) { }

---

So, unless I'm missing something, your example is a reference to a volatile int, not a reference to a non-volatile.

---

Nope. This is easier to show with const:

Code:

---

typedef int & T;
void foo(const T &x) {
  x++; //modifies x, so x is not const. x is just and int &.
}

---

Volatile follows the same rule as const.

"T" is "int &", so "const T &" should be "int & const &", but that folds to "int &". Likewise with "volatile T &", with the same "T", should be "int & volatile &" but also folds to "int &".

EDIT: Clarified as per phantomotap's objection.

Quote:

---

"T" is "int &", so "const T &" should be "int & const &", but that folds to "int &". Likewise with "volatile T &" folds to "int &".

---

->

Quote:

---

"T" is "int &", so "const T &" should be "int & const &", but that folds to "int &". Likewise with "volatile T &" as "int & volatile &", "volatile T &" folds to "int &".

---

Please, please fix that if you get a chance.

Soma

Hmmmm, this is more complicated than I thought....

Quote:

---

Originally Posted by phantomotap

->
Please, please fix that if you get a chance.

Soma

---

I didn't mention the intermediate step of "int & volatile &", but what I said is not wrong. I'll leave it as is, and anyone reading this can see your post anyway and may find it clearer.

Quote:

---

I didn't mention the intermediate step of "int & volatile &", but what I said is not wrong.

---

O_o

I didn't say it was wrong.

I implied it is vague, and it is vague because you like the specificity of the underlying type being a reference.

Without that context, the statement is wrong.

Soma

Quote:

---

Originally Posted by phantomotap

Furthermore, some compilers will allow it without warning; some compilers will allow it always producing a warning; some compilers will not allow it showing an error.

The problems related to producing a potentially "cv-modified" reference or "reference to a reference" is actually why you need "meta-functions" such as `add_const', `add_volatile', `remove_const', `remove_volatile', `add_reference', and `remove_reference'.

For example, the second bit of code fails under several versions of "MSVC", "BCC", and "ECC". (The error relates to "reference to reference is illegal" in general.) To further complicate the issue, the nature or the error depends on how `T' is formed. (In other words, a `T' formed from explicit template, inherited template, or standard traits all chance the error text.) You also have weird issues with overloading errors on some compilers.

Soma

---

I'm pretty sure that MSVE BCC and ECC are wrong here, and the standard does allow this code, just as the compiler I tested on does.

Edit:

Quote:

---

Originally Posted by C++ Standard, in 8.3.2

Cv-qualified references are ill-formed except when the cv-qualifiers are introduced through the use of a typedef (7.1.3) or of a template type argument (14.3), in which case the cv-qualifiers are ignored. [ Example:

Code:

---

typedef int& A;
const A aref = 3; // ill-formed; lvalue reference to non-const initialized with rvalue

---

The type of aref is “lvalue reference to int”, not “lvalue reference to const int”. — end example ]

---

Quote:

---

I'm pretty sure that MSVE BCC and ECC are wrong here, and the standard does allow this code, just as the compiler I tested on does.

---

O_o

Indeed. I had not intended to imply otherwise.

My only intent in providing that information was that anyone actually needing the exact details related to this discussion will necessarily find the related "real world" information useful.

[Edit]
Also, a better bit from the standard would be 8.3.2.6, I think, which spells out both the "reference to reference" aspect and the "cv-modifier" aspect in a single example.
[/Edit]

Soma

Cool. If we agree than there's nothing more to be said. I may have a habit of being a bit pedantic about things like this; I don't necessarily mean to ague, I'm just adding detail.

And yeah, here's the example you mentioned:

Code:

---

int i;
typedef int& LRI;
typedef int&& RRI;

LRI& r1 = i; // r1 has the type int&
const LRI& r2 = i;// r2 has the type int&
const LRI&& r3 = i;// r3 has the type int&

RRI& r4 = i; // r4 has the type int&
RRI&& r5 = i;// r5 has the type int&&

decltype(r2)& r6 = i;// r6 has the type int&
decltype(r2)&& r7 = i;// r7 has the type int&

---