问题标签 [temporary-objects]

我想知道使用 PHP 中的 $_SESSION 变量在会话中存储临时数据（与该会话相关）或从 SQL 数据库存储和检索哪个更有效？

感谢您的时间。

给定以下代码：

我得到以下输出：

虽然我知道这是正确的，但我不确定为什么。有没有 stdc++ 知识的人可以向我解释？

由于它禁止创建临时对象引用转换为方法，这种语法应该是无用的，甚至会使事情变得更加混乱。那么为什么 C++ 会费心支持这种语法呢？

编辑：说实话，我不明白你的表示。考虑到上面的例子，我们通常会使用void outputString(const string ss)而不是。void outputString(const string &ss)我认为正常的事情是“按值传递”方法处理常量/变量和“按引用传递”方法只处理变量。我们应该使用const type-id &而不是const type-id常量的唯一原因是效率，因为“按引用传递”方法仅采用原始常量/对象变量的指针（地址），但“按值传递”方法需要执行复制。

谢谢。

从具有 glibc-2.5-25 (suse 10.2) 的计算机移植到具有 glibc-2.3.2-6 (suse 8.2) 的计算机时，我的代码有一个奇怪的问题。我对临时对象使用了几个方法调用，它们在旧机器上不起作用。

这真的会因为旧的 libc 版本而发生吗？或者它可能是我的 IDE 中的设置（编译器设置）？

我相信表达式T()会创建一个右值（按标准）。但是，以下代码可以编译（至少在 gcc4.0 上）：

我知道从技术上讲这是可能的，因为可以在临时对象上调用成员函数，而上面只是在从 first 创建的 rvalue 临时对象上调用 operator= T()。

但从概念上讲，这就像为右值分配一个新值。允许这样做有充分的理由吗？

编辑：我觉得这很奇怪的原因是它严格禁止内置类型但允许用户定义类型。例如，int(2) = int(3)不会编译，因为那是“赋值中的无效左值”。

所以我想真正的问题是，这种在语言中内置的有点不一致的行为是有原因的吗？还是出于某种历史原因？（例如，仅允许在右值表达式上调用 const 成员函数在概念上会更合理，但不能这样做，因为这可能会破坏一些现有代码。）

似乎 sqlite 不允许我在只读数据库中创建临时视图。我错过了什么吗？如果是临时的，我认为数据库连接模式应该无关紧要。

我什至指定了“PRAGMA temp_store = MEMORY”——它没有帮助。

是否有合理的替代使用视图？

大家好！

我有一个类接收指向“圆”的指针（例如），然后通过一些“链接”方法调整其属性。像这样的东西：

现在我想知道这段代码是否合法：

一方面，我认为在“if”表达式中创建的临时对象将一直存在到该表达式的末尾。因此，对“Radius”和“Center”的调用是合法的。但另一方面，使用对临时变量的引用是一种未定义的行为，在我看来，我正在做这种事情——使用 (*this)，其中“this”是临时变量。这让我有些疑惑，所以，请澄清一下。谢谢！

我创建了一个简单的测试用例，展示了我在正在处理的更大代码库中注意到的奇怪行为。下面是这个测试用例。我依靠 STL Map 的“[]”运算符来创建指向此类结构映射中的结构的指针。在下面的测试用例中，该行...

...给我指针（并在地图中创建一个新条目）。我注意到的奇怪的事情是，这一行不仅导致在映射中创建一个新条目（因为“[]”运算符），而且由于某种原因，它导致结构的析构函数被额外调用两次。我显然错过了一些东西 - 非常感谢任何帮助！谢谢！

上面的代码输出以下...

...但我不明白是什么导致了 TestStruct 的析构函数的前两次调用？（我认为最后一次析构函数调用是有意义的，因为 testStructMap 超出了范围。）

我喜欢在 c++ 中使用哨兵类，但我似乎有一种精神上的痛苦，导致反复编写如下错误：

不用说，这会失败，因为哨兵在创建后立即死亡，而不是按预期在范围结束时死亡。有什么方法可以防止 MySentryClass 被实例化为临时的，这样上面的代码要么无法编译，要么至少在运行时中止并显示错误消息？

What is stack-based references? How are they different from references that are members of objects? Does the Standard talk about these?

I came across this in an article written by Herb Sutter:

Q1: Is the following code legal C++?

A1: Yes. This is a C++ feature… the code is valid and does exactly what it appears to do.

Normally, a temporary object lasts only until the end of the full expression in which it appears. However, C++ deliberately specifies that binding a temporary object to a reference to const on the stack lengthens the lifetime of the temporary to the lifetime of the reference itself, and thus avoids what would otherwise be a common dangling-reference error. In the example above, the temporary returned by f() lives until the closing curly brace. (Note this only applies to stack-based references. It doesn’t work for references that are members of objects.)