Regarding Temporary objects and const-ness !

[coolguyaroundyou]

Consider the following codes:

class abc
{
int i;

public:
abc() : i(0) {}
void func() { .....some code....}
};

void func2(const abc& Obj)
{
.....some code...
}


int main()
{
func2(12);...................//CALL 1

const abc obj;
obj.func();..................// CALL 2

abc().func();...............// CALL 3

return 0;
}

CALL 1 takes place fine by implicit conversion of 5 to an abc object.
But, if the func2() paramater is kept non-const, then it gives
error !! WHY??

CALL2 doesn't take place because we are calling a non-const function
on a const object. That's understood.

If you say that the reason for CALL 1 not taking place in case of non-
const function parameter is that the temporary object created is a
const, then what is the reason for CALL 3 taking place successfully??

I'm really confused regarding this problem.


Are temporary objects const??
If not, then why do we need the prototype of func2 as reference to a
const?

 

[alasham.said]

Consider the following codes:

class abc
{
int i;

public:
abc() : i(0) {}
void  func() { .....some code....}

};

void func2(const abc& Obj)
{
....some code...

}

int main()
{
func2(12);...................//CALL 1

const abc obj;
obj.func();..................// CALL 2

abc().func();...............// CALL 3

return 0;

}

CALL 1 takes place fine by implicit conversion of 5 to an abc object.
But, if the func2() parameter is kept non-const, then it gives
error !! WHY??

Should not compile. You can not initialise const abc& with the
literal 12. Nothing to do with constant correctness.
In order to do that, you should provide an appropriate conversion
constructor.

CALL2 doesn't take place because we are calling a non-const function
on a const object. That's understood.

If you say that the reason for CALL 1 not taking place in case of non-
const function parameter is that the temporary object created is a
const, then what is the reason for CALL 3 taking place successfully??

I'm really confused regarding this problem.

Are temporary objects const??
If not, then why do we need the prototype of func2 as reference to a
const?

You do not _need_ the parameter to be a constant reference. You make
it a constant reference to enforce the fact the the value being passed
to the function parameter will not be changed by the function.

This part of the FAQ may be helpful.
http://www.parashift.com/c++-faq-lite/const-correctness.html

Regards

 

[coolguyaroundyou]

I'M EXTREMELY SORRY EVERYONE

The class also defines a parametrized constructor :

class abc
{
int i;
public:
abc() : i(0) {}
abc(int x) : i(x) {}
void func() { .....some code....}
};

Please review the question!!

 

[Salt_Peter]

Consider the following codes:

class abc
{
int i;

public:
abc() : i(0) {}
void func() { .....some code....}

};

void func2(const abc& Obj)
{
....some code...

}

int main()
{
func2(12);...................//CALL 1

const abc obj;
obj.func();..................// CALL 2

abc().func();...............// CALL 3

return 0;

}

CALL 1 takes place fine by implicit conversion of 5 to an abc object.
But, if the func2() paramater is kept non-const, then it gives
error !! WHY??

CALL2 doesn't take place because we are calling a non-const function
on a const object. That's understood.

If you say that the reason for CALL 1 not taking place in case of non-
const function parameter is that the temporary object created is a
const, then what is the reason for CALL 3 taking place successfully??

I'm really confused regarding this problem.

Are temporary objects const??
If not, then why do we need the prototype of func2 as reference to a
const?

No, temporaries are rvalues. They are not constant and hence the
problem.
What prevents member function func(...) (in CALL 3) to modify the
temp?

Assuming a parametized constructor, fun2 needs a reference to constant
because the lifetime of the temporary needs to be extended.

func2(abc(12));

might fail if it were allowed to compile as is.

Look at it this way:

abc& r = abc();
r.func();

what guarantee do you have that the temporary isn't destroyed before
the second statement?
Well, the language does offer a guarentee.

const abc& r_ = abc();

extends the lifetime of the temporary until the reference_to_const
dies.