使函数返回其输入参数之一的参考是一种好的风格吗? [英] is it a good style to make a function return the referrence of one of its input parameters?

查看:43
本文介绍了使函数返回其输入参数之一的参考是一种好的风格吗?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

代码是这样的:


class Asn_T

{

public:

DataType_T m_data;

};


class MyData

{

MyDataType m_data;

public:

Asn_T&转换(Asn_T& asn)

{

//转换代码到这里


返回asn;

}

};


代码审查中,我们团队的一些成员强烈反对

函数MyData: :Convert()不应该返回Asn_T&,而应该将
声明为返回void,因为返回值很少使用,

并且它足够了使用输入参数。


但我认为这种功能声明更灵活,因此

更合理。

i想知道你对它的看法。谢谢

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.

but i think this style of function declaration is more flexible, thus
is more reasonal.
i want to know your opinion about it. thanks

推荐答案

steve yee写道:
steve yee wrote:
Asn_T&转换(Asn_T& asn)
Asn_T& Convert(Asn_T& asn)




为iostreams重载的所有运算符<<()方法都是这样做的,因为链接的便利性很好。这只是一种便利。

foo(bar).baz()。zone()。etc()。


对于更复杂的设计,考虑一个有时会返回其

输入参数的函数,有时会返回其他内容。


-

Phlip
http://c2.com/cgi/wiki?ZeekLand < ; - 不是博客!!!



All the operator<<() methods overloaded for iostreams do that, as a
convenience for chaining. It''s just a convenience.
foo(bar).baz().zone().etc().

For a more complex design, consider a function that sometimes returns its
input parameter, and sometimes returns something else.

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!


*史蒂夫:
代码是这样的:

class Asn_T
公共:
DataType_T m_data;
};

类MyData
{
MyDataType m_data;
public:
Asn_T&转换(Asn_T& asn)
{
//转换代码到这里

返回asn;
}
};
在代码审查中,我们团队的一些成员强烈主张,函数MyData :: Convert()不应该返回Asn_T&,而应该声明为返回void,因为返回值很少使用,
并且它足以使用输入参数。

但我认为这种功能声明更灵活,因此更合理。<我想知道你对它的看法。谢谢
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.

but i think this style of function declaration is more flexible, thus
is more reasonal.
i want to know your opinion about it. thanks




很难说不知道更多。


一方面,这种技术有时用于实现自然

链接,如在标准库的iostreams中,或在命名的

参数idiom *中。


另一方面它有时用于实现难以破译的不自然的简洁

符号。


如果不得不猜测,我'' d猜测后者,因为它是对'

参数的引用',而不是对象本身的引用。


但是在第三方面,返回对参数的引用正是

你在实现iostream插入操作符时所做的事情,比如


std :: ostream& operator<<(std :: ostream& stream,T const& obj)

{

return(stream<< obj.asString());

}


一个人肯定不会建立一个一般原则,即
会禁止iostream插入器。


*)< url:http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.18>


-

答:因为它弄乱了人们通常阅读文字的顺序。

问:为什么这么糟糕?

A:热门帖子。

问:usenet和电子邮件中最烦人的是什么?



Difficult to say without knowing more.

On the one hand, this technique is sometimes used to implement natural
chaining, as in the standard library''s iostreams, or in the named
argument idiom*.

On the other hand, it''s sometimes used to implement unnatural "concise"
notation that is difficult to decipher.

If had to guess, I''d guess the latter, because it''s a reference to the
argument that''s returned, not a reference to the object itself.

But on the third hand, returning a reference to the argument is exactly
what you do when implementing an iostream insertion operator, like

std::ostream& operator<<( std::ostream& stream, T const& obj )
{
return (stream << obj.asString());
}

And one certainly wouldn''t want to establish a general principle that
would forbid iostream inserters.

*) <url: http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.18>

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?


steve yee写道:
steve yee wrote:
类Asn_T
公开:
DataType_T m_data;
};

类MyData
{
MyDataType m_data;
公开:
Asn_T&转换(Asn_T& asn)
{
//转换代码到这里

返回asn;
}
};
在代码审查中,我们团队的一些成员强烈主张,函数MyData :: Convert()不应该返回Asn_T&,而应该声明为返回void,因为返回值很少使用,
并且它足以使用输入参数。


正如我所理解的那样,你的逻辑的要点是将MyData对象的
转换为Asn_T,并将结果存储在Asn_T中。 />
通过引用传入,对吧?

但是我认为这种函数声明更灵活,因此
更合理。
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.
Just so I understand correctly, the gist of your logic is to convert
the MyData object into an Asn_T, and store that result in the Asn_T
passed in by reference, right?
but i think this style of function declaration is more flexible, thus
is more reasonal.




"灵活这是一个有趣的词 - 每个人都有一个不同的想法(或几个b $ b)。你看到上面的代码是灵活的,因为它给你

两种方法来获得返回值。我认为它会促进

*不灵活*,因为它会增加不一致性和过度的b $ b b宽接口。你提供了两种方法来做一件事,而且b $ b会产生两者的开销。以两种不同的方式使用意味着

你基本上有两个接口,这使得更难更改

你的代码 - * *那种灵活性你应该关心。

在讨论高哲学软件设计原则时,总是记住*为什么*它们很重要,否则它很容易陷入

像这样的陷阱。


那就是说,我会用我认为最直接的签名来实现它:
Asn_T MyData :: Convert()const;


我把它变为const,因为我不认为会员函数叫做

Convert()如果修改了*这将是合理的。我更愿意简单地按价值回报
,因为它提供了更少的机会来搞砸

对象的生命周期。我省略了参数,因为它是不必要的,

,除非你没有告诉我们这个函数需要做什么。
需要做什么。 br />

卢克



"Flexible" is a funny word -- everyone has a different idea (or
several) about it. You see the above code as flexible because it gives
you two ways to get the return value. I would argue that it promotes
*inflexibility*, because it promotes inconsistency and an excessively
wide interface. You''re providing two ways to do one thing, and
incurring the overhead of both. Being used in two different ways means
you''ve basically got two interfaces, which makes it harder to change
your code -- *that* is the kind of flexibility you should care about.
When debating high philosophical software design principles, always
remember *why* they''re important, otherwise it''s easy to fall into
traps like this.

That said, I''d implement it with what I consider the most
straightforward signature:
Asn_T MyData::Convert() const;

I made it const, because I don''t think a member function called
Convert() would be reasonable if it modified *this. I prefer to simply
return by value, because it provides less opportunities to screw up
object lifetimes. I left out the parameter because it''s unnecessary,
unless there''s something you''re not telling us about what this function
needs to do.

Luke


这篇关于使函数返回其输入参数之一的参考是一种好的风格吗?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆