传递参考而不是传递指针=一个坏主意？ [英] Pass-by-reference instead of pass-by-pointer = a bad idea?
问题描述
嗨！
我一直在考虑使用引用传递参数来代替
指针以强调参数必须是
对象。
例如：
void func（Objec& object）; //对象必须是一个对象
而不是
void func（Object * object）; //对象可以为NULL
我相信这是一个好主意，因为在参考的情况下，它是'
清楚NULL不是一个选项。很明显，当一个指针被指望时，NULL是一个
选项（说明显而易见的:-)）。代码
变得更加自我记录。
任何评论为什么这可能是一个坏主意或者你认为它只是
a品味？
/ H
A先生写道：< blockquote class =post_quotes>嗨！
我一直在考虑使用引用传递参数，而不是指针，以强调参数必须是一个
对象。
例如：
void func（Objec& object）; //对象必须是一个对象
而不是
void func（Object * object）; //对象可以为NULL
我相信这是一个好主意，因为在参考案例中，它明确表示NULL不是一个选项。很明显，当指针被指示时，NULL是一个
选项（说明显而易见的:-)）。代码
变得更加自我记录。
任何关于为什么这可能是一个坏主意的评论，或者你认为它只是一个品味问题？
/ H
这是正确的做法。我甚至会说，除非你明确需要一个
指针（即它需要重新安装）某些原因和/或NULL有一个
有用的含义）。原因与你说的几乎相同。
参考文献（对我来说至少）更容易使用，并且没有
担心意外尝试访问一个对象通过NULL引用。
-Alan
A先生写道：
嗨！
我一直在考虑使用引用来传递参数，而不是指针，以强调参数必须是
对象。
<例如：
void func（Objec& object）; //对象必须是一个对象
而不是
void func（Object * object）; //对象可以为NULL
我相信这是一个好主意，因为在参考案例中，它明确表示NULL不是一个选项。很明显，当指针被指示时，NULL是一个
选项（说明显而易见的:-)）。代码
变得更加自我记录。
任何关于为什么这可能是一个坏主意的评论，或者你认为它只是一个品味问题？
/ H
不幸的是，有不同的有利位置我们可以从中查看
函数：声明，定义和调用。每个人都拥有它自己的暴露和隐藏信息。有人认为传递一个指针
更明确，并使代码更容易阅读。我倾向于同意。
AFAIK，你*可以*在你的例子中将null传递给func（），编译器
将接受它。当你这样做时，你的代码会出现段错误。如果你传递了一个
指针，你可以在访问之前检查null。因此，我建议使用指针代替参考。
-
如果我们的假设是关于任何事情而不是关于某个或者更多
特定的东西，然后我们的推论构成数学。因此，数学可能被定义为我们永远不知道我们所讨论的是什么，以及我们所说的是否属实的主题.- Bertrand Russell
Steven T. Hatton写道：A先生写道：
嗨！
我'我一直在考虑使用引用而不是指针来传递参数，以强调参数必须是一个
对象。
例如：
void func（Objec& ;对象）; //对象必须是一个对象
而不是
void func（Object * object）; //对象可以为NULL
我相信这是一个好主意，因为在参考案例中，它明确表示NULL不是一个选项。很明显，当指针被指示时，NULL是一个
选项（说明显而易见的:-)）。代码
变得更加自我记录。
以上段落是正确的。尝试传递任何除了
ref对现有的所需类型的实例将导致
编译时错误。除非有一些特定的理由要传递
指针，否则通常首选使用ref'。
任何评论为何这可能是一个坏主意或者你认为它只是一个品味问题？
/ H
不幸的是，我们有不同的有利位置查看功能：声明，定义和调用。每个人都有自己的暴露和隐藏信息。有人认为传递指针更明确，并使代码更容易阅读。我倾向于同意。
AFAIK，您*可以*在您的示例中将null传递给func（），编译器将接受它。当你这样做时，你的代码会出现段错误。如果传递
指针，则可以在访问之前检查null。因此，我建议使用指针而不是引用。
如果函数接受ref，则无法传递NULL 。
尝试传递NULL会导致编译错误。
例如：
#include< iostream>
struct Stuff
{
int a;
double b;
};
void func（Stuff& obj）
{
obj.a = 1;
}
int main（）
{
东西;
func（s）;
func（0）; //导致编译错误
返回0;
}
拉里
Hi!
I''ve been thinking about passing parameteras using references instead
of pointers in order to emphasize that the parameter must be an
object.
Exemple:
void func(Objec& object); //object must be an object
instead of
void func(Object* object); //object can be NULL
I belive that this is a good idea since , in the reference case, it''s
clear that NULL is not an option. It''s also clear that NULL is an
option when a pointer is expected (stating the obvious :-) ). The code
becomes somewhat more self-documenting.
Any comments on why this could be a bad idea or do you think it''s just
a matter of taste?
/H
Mr A wrote:Hi!
I''ve been thinking about passing parameteras using references instead
of pointers in order to emphasize that the parameter must be an
object.
Exemple:
void func(Objec& object); //object must be an object
instead of
void func(Object* object); //object can be NULL
I belive that this is a good idea since , in the reference case, it''s
clear that NULL is not an option. It''s also clear that NULL is an
option when a pointer is expected (stating the obvious :-) ). The code
becomes somewhat more self-documenting.
Any comments on why this could be a bad idea or do you think it''s just
a matter of taste?
/H
That is exactly the right way to do it. I''d go so far as to say always
prefer a reference over a pointer unless you have an explicit need for a
pointer (i.e. it needs to be reseated for some reason and/or NULL has a
useful meaning). The reason being pretty much the same that you stated.
References are (for me at least) easier to work with, and there is no
worry of accidentally trying to access an object through a "NULL reference".
-Alan
Mr A wrote:
Hi!
I''ve been thinking about passing parameteras using references instead
of pointers in order to emphasize that the parameter must be an
object.
Exemple:
void func(Objec& object); //object must be an object
instead of
void func(Object* object); //object can be NULL
I belive that this is a good idea since , in the reference case, it''s
clear that NULL is not an option. It''s also clear that NULL is an
option when a pointer is expected (stating the obvious :-) ). The code
becomes somewhat more self-documenting.
Any comments on why this could be a bad idea or do you think it''s just
a matter of taste?
/H
Unfortunately, there are different vantage points from which we view a
function: declaration, definition and invocation. Each has it''s own
exposed and hidden information. It has been argued that passing a pointer
is more explicit, and makes the code easier to read. I tend to agree.
AFAIK, you *can* pass a null to func() in your example, and the compiler
will accept it. Your code will segfault when you do so. If you pass a
pointer, you can check for null, before accessing it. I, therefore,
suggest using a pointer instead of a reference.
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell
Steven T. Hatton wrote:Mr A wrote:Hi!
I''ve been thinking about passing parameteras using references instead
of pointers in order to emphasize that the parameter must be an
object.
Exemple:
void func(Objec& object); //object must be an object
instead of
void func(Object* object); //object can be NULL
I belive that this is a good idea since , in the reference case, it''s
clear that NULL is not an option. It''s also clear that NULL is an
option when a pointer is expected (stating the obvious :-) ). The code
becomes somewhat more self-documenting.
The above paragraph is correct. Attempting to pass ANYTHING except
a ref to an existing instance of the required type will cause a
compile-time error. Unless there is some specific reason to pass a
pointer, using ref''s is usually preferred.
Any comments on why this could be a bad idea or do you think it''s just
a matter of taste?
/H
Unfortunately, there are different vantage points from which we view a
function: declaration, definition and invocation. Each has it''s own
exposed and hidden information. It has been argued that passing a pointer
is more explicit, and makes the code easier to read. I tend to agree.
AFAIK, you *can* pass a null to func() in your example, and the compiler
will accept it. Your code will segfault when you do so. If you pass a
pointer, you can check for null, before accessing it. I, therefore,
suggest using a pointer instead of a reference.
If a function takes a ref, then NULL can not be passed.
Attempting to pass NULL causes a compile error.
For example:
#include <iostream>
struct Stuff
{
int a;
double b;
};
void func(Stuff& obj)
{
obj.a = 1;
}
int main()
{
Stuff s;
func(s);
func(0); // causes a compile error
return 0;
}
Larry
这篇关于传递参考而不是传递指针=一个坏主意？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
