Returning const reference value from functions

[Sree]

Hello All,
When will it be benefical to return a value from a function as a const reference
?

Say I have classes like this

class B {
public:
int someValue1;
int someValue2;
void ChangeValue();
void ConstFunc() const;
};

void B::ChangeValue( )
{
int tmp = someValue1;
someValue1 = someValue2;
someValue2 = tmp;
}
class A {
public :
int value;
void inspect(const B& b);
const B& returnConstRef( );
private :
int someInt;
B classB;
};

const B& A::returnConstR ef()
{
return classB;
}

In the above class, returnConstRef returns a const reference to B. So whatever
we get like this should not be able to change class B like below. Also the
compiler should not allow me to assign a non-const class B (classB) to classA.
returnConstRef( ).

A classA;
B classB = classA.returnCo nstRef();
classB.ChangeVa lue();

With the above code there is no problem with the compiler. I am wrong some where
in my understanding of the returning values by reference, Can somebody please
correct ?

Thanks in advance
KInd.
--
Use our news server 'news.foorum.co m' from anywhere.
More details at: http://nnrpinfo.go.foorum.com/

[Karl Heinz Buchegger]

Sree wrote:

Hello All,
When will it be benefical to return a value from a function as a const reference
?
When the cost of returning by value is to high due to copying of the
return value.
With builtin types like int, double, char, ... this is practically never
the case. User defined types need to have a closer inspection.

[snip]
Also the
compiler should not allow me to assign a non-const class B (classB) to classA.
returnConstRef( ).
Maybe I read something different to what you intended. But: Why should
the compiler not allow this?

A classA;
B classB = classA.returnCo nstRef();
classB.ChangeVa lue();

That does something completely different.
A new B object is constructed, which is initialized from the
B object in A.
After that classB and the B object in classA have nothing in common.
This would not change, if you didn't return a const reference, but
a non const instead.
--
Karl Heinz Buchegger
kb******@gascad .at

[Richard Herring]

In message <20************ *******@foorum. com>, Sree
<no************ @f-m.fm> writes

Hello All,
When will it be benefical to return a value from a function as a const
reference
?
See the thread "Read-only, as opposed to const member" for a lot more
debate on this issue ;-)

Say I have classes like this

class B {
public:
int someValue1;
int someValue2;
void ChangeValue();
void ConstFunc() const;
};

void B::ChangeValue( )
{
int tmp = someValue1;
someValue1 = someValue2;
someValue2 = tmp;
}
class A {
public :
int value;
void inspect(const B& b);
const B& returnConstRef( );
private :
int someInt;
B classB;
};

const B& A::returnConstR ef()
{
return classB;
}

In the above class, returnConstRef returns a const reference to B. So whatever
we get like this should not be able to change class B like below. Also the
compiler should not allow me to assign a non-const class B (classB) to classA.
returnConstRef ().

A classA;
B classB = classA.returnCo nstRef();
This constructs a new B which is a *copy* of the reference returned by
returnConstRef( ). The new B object has no connection with the one in
classA.
classB.ChangeVa lue();
And this can therefore modify the new copy.

Did you perhaps mean to write

B const & classB = classA.returnCo nstRef();
// now classB is a (const) reference to classA.classB
classB.ChangeVa lue(); // this won't compile
?
With the above code there is no problem with the compiler. I am wrong
some where
in my understanding of the returning values by reference, Can somebody please
correct ?

--
Richard Herring

[JKop]

Sree posted:

In the above class, returnConstRef returns a const reference to B. So
whatever we get like this should not be able to change class B like
below.

Wouldn't it be nice if you could make the B object read-only.

class A
{
read-only B objectB;
};
I've written another thread about this entitled "Read only, as opposed to
const member variable". Don't look at my original post, but my second one in
the thread. Essentially it does this:

int main(void)
{
A a;

TakesB(a.object B);

a.objectB = 4; //Compile ERROR

//Essentially, it is read-only
}
-JKop