在 C++ 中，指针传递比引用传递有什么好处？
最近，我看到了许多选择通过指针传递函数参数而不是通过引用传递的示例。这样做有什么好处吗？
例子：
func(SPRITE *x);
调用
func(&mySprite);
对比
func(SPRITE &x);
调用
func(mySprite);
【问题讨论】：
new 来创建指针以及由此产生的所有权问题。
标签： c++ pointers parameter-passing pass-by-reference
nothing。这可用于提供可选参数。string s = &str1 + &str2;。 void f(const T& t); ... f(T(a, b, c));，不能像那样使用指针，因为您不能获取临时对象的地址。【讨论】：
指针可以接收NULL参数，引用参数不能。如果您有可能想要传递“无对象”，请使用指针而不是引用。
此外，通过指针传递可以让您在调用站点显式查看对象是通过值传递还是通过引用传递：
// Is mySprite passed by value or by reference? You can't tell
// without looking at the definition of func()
func(mySprite);
// func2 passes "by pointer" - no need to look up function definition
func2(&mySprite);
【讨论】：
func2 passes by reference。虽然我很欣赏您的意思是从高级角度“通过引用”传递，通过在代码级角度传递指针来实现，但这非常令人困惑（请参阅stackoverflow.com/questions/13382356/…）。
func(int& a) 在任何版本的标准中都不是有效的 C。您可能无意中将文件编译为 C++。
func(*NULL)。然后在函数内部，使用if (&x == NULL) 进行测试。我想这看起来很难看，但是指针和引用参数之间的区别是语法糖。
我喜欢来自“cplusplus.com”的一篇文章的推理：
当函数不想修改参数且值易于复制时传值（ints、doubles、char、bool等...简单类型。std::string、std:: vector 和所有其他 STL 容器都不是简单类型。）
当值复制成本高且函数不想修改指向的值且 NULL 是函数处理的有效预期值时，通过 const 指针传递。
当值复制成本高且函数想要修改指向的值且 NULL 是函数处理的有效预期值时，通过非常量指针传递。
当值复制成本高且函数不想修改引用的值时，通过 const 引用传递，如果使用指针，NULL 将不是有效值。
李>当值复制成本高且函数想要修改引用的值时，通过非连续引用传递，如果使用指针代替，NULL 将不是有效值。
李>在编写模板函数时，没有一个明确的答案，因为有一些权衡需要考虑，这超出了本讨论的范围，但只要说大多数模板函数通过以下方式获取参数就足够了值或 (const) 引用，但是因为迭代器语法类似于指针的语法（星号表示“取消引用”），任何期望迭代器作为参数的模板函数也将默认接受指针（并且不检查 NULL，因为 NULL迭代器概念有不同的语法）。
我从中得到的是，选择使用指针或引用参数的主要区别在于 NULL 是否是可接受的值。就是这样。
值是输入、输出、可修改等，毕竟应该在关于函数的文档/cmets中。
【讨论】：
Allen Holub 的“足够的绳子射中自己的脚”列出了以下 2 条规则：
120. Reference arguments should always be `const`
121. Never use references as outputs, use pointers
他列出了向 C++ 添加引用的几个原因：
const 引用允许您在避免复制的同时拥有按值传递的语义他的主要观点是不应将引用用作“输出”参数，因为在调用站点没有指示参数是引用参数还是值参数。所以他的规则是只使用const 引用作为参数。
就个人而言，我认为这是一个很好的经验法则，因为它可以更清楚地说明参数何时是输出参数。然而，虽然我个人总体上同意这一点，但我确实允许自己被团队中其他人的意见所左右，如果他们主张将输出参数作为参考（一些开发人员非常喜欢它们）。
【讨论】：
对前面帖子的澄清：
引用是不获得非空指针的保证。 （虽然我们经常这样对待它们。）
虽然代码非常糟糕，就像带你离开木棚的糟糕代码一样，但以下代码将编译并运行：（至少在我的编译器下。）
bool test( int & a)
{
return (&a) == (int *) NULL;
}
int
main()
{
int * i = (int *)NULL;
cout << ( test(*i) ) << endl;
};
我对引用的真正问题在于其他程序员，以下称为 IDIOTS，他们在构造函数中分配，在析构函数中释放，并且无法提供复制构造函数或 operator=()。
foo(BAR bar) 和 foo(BAR & bar) 之间突然有了天壤之别。 （自动按位复制操作被调用。析构函数中的释放被调用两次。）
谢天谢地，现代编译器会采用这种对同一指针的双重释放。 15年前，他们没有。 （在 gcc/g++ 下，使用 setenv MALLOC_CHECK_ 0 重新访问旧方法。）在 DEC UNIX 下，相同的内存被分配给两个不同的对象。那里有很多调试乐趣...
更实际：
【讨论】：
*i时，你的程序就会有未定义的行为。例如，编译器可以看到这段代码并假设“好的，这段代码在所有代码路径中都有未定义的行为，所以这整个函数一定是不可访问的。”然后它将假设没有采用导致此功能的所有分支。这是定期执行的优化。
就表达意图而言，这里的大多数答案都未能解决在函数签名中具有原始指针的固有歧义。问题如下：
调用者不知道指针是指向单个对象，还是指向对象“数组”的开头。
调用者不知道指针是否“拥有”它所指向的内存。 IE，该功能是否应该释放内存。 （foo(new int) - 这是内存泄漏吗？）。
调用者不知道nullptr是否可以安全地传递给函数。
所有这些问题都通过引用解决：
引用始终指向单个对象。
引用从不拥有它们所引用的内存，它们只是内存的视图。
引用不能为空。
这使得引用更适合一般用途。然而，参考并不完美 - 有几个主要问题需要考虑。
& 运算符来表明我们确实在传递一个指针。例如，int a = 5; foo(a); 这里根本不清楚 a 是通过引用传递的，并且可以修改。 std::optional<T&> 无效（有充分的理由），指针为我们提供了您想要的可空性。所以看来，当我们想要一个显式间接的可空引用时，我们应该使用T* 对吗？错了！
在我们对可空性绝望的情况下，我们可能会找到T*，而忽略前面列出的所有缺点和语义模糊性。相反，我们应该追求 C++ 最擅长的：抽象。如果我们简单地编写一个包装指针的类，我们将获得表现力，以及可空性和显式间接性。
template <typename T>
struct optional_ref {
optional_ref() : ptr(nullptr) {}
optional_ref(T* t) : ptr(t) {}
optional_ref(std::nullptr_t) : ptr(nullptr) {}
T& get() const {
return *ptr;
}
explicit operator bool() const {
return bool(ptr);
}
private:
T* ptr;
};
这是我能想到的最简单的界面，但它可以有效地完成工作。 它允许初始化引用、检查值是否存在以及访问该值。我们可以这样使用它：
void foo(optional_ref<int> x) {
if (x) {
auto y = x.get();
// use y here
}
}
int x = 5;
foo(&x); // explicit indirection here
foo(nullptr); // nullability
我们已经实现了我们的目标！现在让我们看看与原始指针相比的好处。
nullptr 可以传入，因为函数作者明确要求optional_ref
我们可以从这里使接口更复杂，例如添加相等运算符，一个单子get_or 和map 接口，一个获取值或抛出异常的方法，constexpr 支持。这可以由您完成。
总之，不要使用原始指针，而是推理这些指针在您的代码中的实际含义，并利用标准库抽象或编写您自己的抽象。这将显着改进您的代码。
【讨论】：
不是真的。在内部，通过引用传递实际上是通过传递被引用对象的地址来执行的。因此，通过指针传递确实没有任何效率提升。
但是，通过引用传递确实有一个好处。保证您有一个正在传入的任何对象/类型的实例。如果您传入一个指针，那么您将面临收到 NULL 指针的风险。通过使用按引用传递，您将隐式 NULL 检查向上推到函数的调用者。
【讨论】：