问题标签 [pass-by-const-reference]

以下程序

如果用这样的文字调用将起作用

但没有const它就行不通。

那么引用如何const继续指向 R 值（匿名变量）？

请允许我先发布我的代码：

我知道Fun(iTest);会生成一个新的临时变量（类型转换），但我想知道临时变量是否是常量？

如果否：为什么我不能将临时变量传递给short &

如果是：我有另一个这样的代码：

如果返回的临时变量MOCreator() 是常量，为什么临时变量可以调用非常量成员函数？

我的问题是：</p>

1) C++ 中的临时变量和常量有什么区别？

2）Thinking in C++（第507页）中有一句话。句子对吗？为什么？：

临时对象自动为const

有人问我一个简单的问题，我在解决问题的过程中遇到了更多问题。我知道它们可能是一个非常常见的问题，我在网上搜索了很长时间。我也得到了很多不同的答案。但我现在对此更加困惑。

提前致谢。

假设我想实现一些简单的数学函数；例如，假设它是 (C++17's) 的重新实现std::clamp：此函数接受一个数字、一个下限和一个上限，如果它超出了它们定义的范围，则将该数字设置为这些边界之一。如果它是一个具体的数字类型，比如说int，我会写：

但如果它是一个模板，我看到可能是标准将使用的示例实现const&使用's 而不是值。因此，使引用变得更简单，例如：

我的问题是：

• 使用 const 引用有什么好处，因为T's 是简单的数字类型？
• 同上，对于将单个数字包装为数据成员（例如std::chrono持续时间）的一些抽象事物的类型？
• 为什么在const&任何相对简单的（constexpr？）无副作用的数学函数的一般情况下取一个值是一个更好的主意？

笔记：

• 我意识到，const&当您拥有某种 k 维向量类型或boost::rationals 和其他类似数字的类型时，可能会开始有意义；但即便如此，编译器不会优化复制吗？
• 我不是在问任何任意的 C++ 函数，以及它是否应该只按值获取参数，这显然是个坏主意。

又名。如何防止const&参数意外绑定到临时参数？

我们有一个基本上看起来像这样的类：

也就是说，这些对象将“保留”它们通过的 const-ref。

我们有一个错误，该observe函数意外地传递了一个临时对象 - 在这种情况下永远不会有效。

我们有哪些选项可以防止意外绑定到临时对象？

将签名更改为在(const T* px)技术上可以工作（获取临时地址是编译器警告=错误）由于其他原因它不是很有吸引力。

_{旁注：是的，这总是会有潜在的生命周期管理问题，但到目前为止，由于其有限的使用模式，真实的东西工作得很好——但在实践中已经观察到意外传递临时对象，所以我们可能希望首先解决这个问题。}

我制作了一个自定义类，其中涉及大量的数字和字符串计算。通过只提供访问器而不提供修改器，我使我的类不可变。一旦构造了对象，就不会更改它的单个属性。

我的问题是，目前我所有的函数都是按值传递的。如果您有一个不可变对象，是否还需要通过引用传递？由于需要不断创建副本，因此按值传递是否会浪费内存？

例如：

我对 shared_ptr 感到困惑，我的主要问题是：当我执行以下操作时，c++ 是否会创建一个新对象（shared_ptr 对象）？

显然，Func1(v1)是由 ref 传递的。但是，怎么样Func2(v1)？

编译器会在后面做以下事情吗？

我关心它，因为Func2可能比Func1.

非常感谢您的帮助！

让我们考虑以下不正确的代码：

g++ 6.3.0 和 clang 3.8.1 都会在没有警告的情况下编译此代码，即使使用-W -Wall -Werror.

为什么结果不像人们天真地期望的那样？std::string创建的对象的生命周期 const char *仅限于构造函数的范围。因此，当foo()构造函数返回时，该foo::s字段具有对不存在对象的引用。卡布姆。

如果有人理解这个想法，很容易引入修复。它可以是显式创建std::string对象并将其作为参数传递：

另一种我认为更安全的方法是将foo::s字段声明更改为：

制作参数的本地不可修改副本，但它增加了复制对象的成本。好吧，在这个例子中，std::string 的复制不会自动导致进行深度复制，但对于自己实现的类来说，这可能是完全不同的事情。

对于 C++11，几乎没有其他可用的方法，如本答案中所指定，但是 - 例如 - 在嵌入式 Linux 环境中，当您坚持使用旧编译器和一些遗留代码时，它不一定是一个相当大的选择。

但是，无论程序员选择何种解决方案，都必须知道存在问题。即使我正确地编写了我的代码，我也愚蠢地认为编译器会足够聪明地检测出明显危险的情况，如果其他开发人员会陷入传递const char *参数的陷阱。然而，我决定编写一些代码来检查编译器的行为，我很失望——很容易陷入引用已经不存在的对象的陷阱。

将临时对象作为 const 引用传递是一种公认​​的危险，它已在 C++11 中以某种方式解决，但仍将责任转嫁给程序员以积极抵制这种行为。那么，期望编译器发出警告是合理的，还是应该依赖外部静态分析工具？

我最近阅读了一篇关于 C++ 中新的移动语义的文章。这是关于如何最好地为大对象实现返回值的困惑。结论是，只需像按副本返回一样实现它，让编译器决定移动是否最有效。

现在我想知道这是否同时适用于函数参数。

目前我使用这样的 const 引用：

而不是简单的副本：

通过 const 引用传递的用于复制大对象的参数是否仍然是 C++11 及更高版本中的最佳实践？

想象一下下面的简化代码：

(1) 抛开优化不谈，当 42 被传递给 时会发生什么foo？

编译器是否将 42 粘贴在某处（在堆栈上？）并将其地址传递给foo?

(1a) 标准中是否有任何规定在这种情况下要做什么（或者它是否严格取决于编译器）？

现在，想象一下稍微不同的代码：

它不会链接，除非我定义int bar::baz;（由于 ODR？）。

(2) 除了 ODR，为什么编译器不能做上面 42 所做的事情？

简化事情的一个明显方法是定义foo为：

但是，如果是模板，该怎么办？例如：

(3) 有没有一种优雅的方式来告诉foo接受x原始类型的值？还是我需要用 SFINAE 或类似的东西专门化它？

编辑：修改了内部发生foo的事情，因为它与这个问题无关。

假设你有一组指针（是的......）：

然后假设你想从 SomeType 的 const 方法中搜索这个集合：

这行不通。方法中的thisptr 是 a const SomeType *const，我不能放入find. 问题是find需要一个 const-ref，在这种情况下，这意味着传递的指针被视为 const，而不是它指向的东西。

有没有办法顺利解决这个问题（不改变设置的模板类型）？