Re: is it a good style to make a function return the referrence of one of its input parameters?
steve yee wrote:
the code is like this:
class Asn_T
{
public:
DataType_T m_data;
};
class MyData
{
MyDataType m_data;
public:
Asn_T& Convert(Asn_T& asn)
{
// coverting codes goes here
return asn;
}
};
in a code review, some members of our team argued strongly that the
function MyData::Convert() should not return Asn_T&, instead, it should
be declared as returning void,because the return value is seldom used,
and it's enough to use the input parameter.
Several people have pointed that returning an Asn_T would allow
function chaining. However, the chaining idiom is usually seen using
the object on which the function was called
my_object.set_value(a).set_value(b).set_value(c);
not on one of its parameters.
IMO, either return an object or pass one by reference, but don't do
both.
but i think this style of function declaration is more flexible, thus
is more reasonal.
By "reasonal", do you mean "reasonable"? If so, something flexible is
not necessarily reasonable. There is a compromise to make between
flexibility (genericity) and usability.
If I understand your code correctly, Convert() converts the object to
an Asn_T. In this case, it makes more sense to create a new Asn_T
object and to return it by value. If I don't have an Asn_T prior to
calling Convert(), I must create one before.
void f(MyData& d)
{
Asn_T a;
d.Convert(a);
}
I read this as "I am creating an Asn_T and then using it to convert a
MyData". This implies default construction of an Asn_T (which could be
expensive) and is less clear semantically than
void f(MyData& d)
{
Asn_T a = d.Convert();
}
which I read as "I am creating an Asn_T specifically to convert a
MyData". Convert() should therefore look like
Asn_T MyData::Convert()
{
Asn_T a;
// ...
return a;
}
Jonathan