问题标签 [c++14]

这涉及 C++ 问题http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1402的解决。概括：

（问题是我们收到了这个片段的错误，即使编译器可以简单地使用“S”的复制构造函数，就像用户显式编写“wrap”的移动构造函数时那样。问题已解决为在重载决议期间忽略已删除的移动构造函数（和赋值运算符），因此根据需要使用上面的复制构造函数。）

在起草该决议时，对该决议发表了以下评论：

与复制相关的隐式/默认移动操作没有其他限制。这意味着虚拟基础中的移动分配是危险的（编译器可能应该警告）[...] 但是我们在 Batavia 中决定我们不会保留所有 C++03 代码以防止隐式移动操作，我认为该解决方案提供了显着的性能优势。

有人可以描述一下虚拟基地移动分配运算符的问题吗？

考虑这个C++1y代码（现场示例）：

编译器（GCC 4.8.1）慷慨地抛出了这个错误：

main.cpp：在函数“int main()”中：
main.cpp:8:18：错误：在扣除“auto”之前使用“auto foo()”<br> std::cout << foo();
                   ^

我如何foo()在这里提前声明？或者更恰当地说，是否可以前向声明foo()？

我还尝试编译我试图在文件中声明foo()的代码，就像上面在.h文件中定义的那样，在我的文件中包含和对 的调用，并构建它们。foo().cpp.hmain.cppint main()foo()

发生了同样的错误。

C++11 给了我们很好的std::array，这需要在编译时知道大小：

现在，我碰巧有一些旧的short*缓冲区要包装，它们的大小仅在运行时才知道（当然是）。

C++14 将定义std::dynarray以涵盖这种情况，但dynarray在 GCC 4.7 和 Clang 3.2 中尚不可用。

那么，有没有人知道一个与（在效率方面）相当std::array但不需要在编译时指定大小的容器？我怀疑 Boost 已经为我准备好了一些东西，尽管我找不到任何东西。

我有一个四/八叉树数据结构。我将一个单元格的子索引/ptrs 存储在一个数组中。数组中的每个位置都表示一个孩子相对于其父母的位置，例如在 2D 中：

我知道最大子节点数是Integer类型可以表示的值的子集。-1因此，我可以通过使用诸如forInteger = int或std::numeric_limits<unsigned>::max()for之类的“魔术”值来确定单元格是否缺少孩子Integer = unsigned。这是std::optional<Integer>不能假设的。

据我了解，这种魔法值的使用是std::optional. 尽管如此，我还是担心std::vector<std::optional<int>>内部循环的性能。

所以，

• 的性能std::vector<std::optional<int>>会比 的差std::vector<int>吗？（我已经在比较“不存在”的值了）。

• 或者，是否可以std::optional优化实现以提供与 raw 相同的性能int？如何？

在我的数据结构中混合std::optional函数的返回类型和魔法值听起来是个非常糟糕的主意。我更喜欢保持一致并使用其中一个（至少在相同的上下文中）。虽然我可以重载执行与幻数比较的函数：

对于可选类型。

C++14 草案包括运行时大小的数组和std::dynarray容器。据我所知，两者之间唯一真正的区别是std::dynarray具有 STL 接口（例如 、、begin等），而运行时大小的数组则没有。那么为什么 C++14 两者都需要呢？endsize

我知道运行时大小的数组是核心语言的std::dynarray一部分，同时是标准库的一部分，但提案std::dynarray清楚地表明作者希望编译器在许多情况下提供特殊支持，std::dynarray以便它可以同样高效尽可能，即与运行时大小的数组一样高效。因此，语言/库的区别似乎有些人为。

那么，为什么 C++14 既需要运行时大小的数组又需要std::dynarray? 鉴于它std::dynarray具有更丰富的（STLified）接口，为什么不直接删除运行时大小的数组，假设std::dynarray可以以相同的运行时效率实现呢？

澄清

当我谈论“运行时大小的数组”时，我指的是N3639中描述的新的 C++14 核心语言功能，而不是传统的 C 数组或 VLA 或 C++11 中的任何内容。

C++11 添加了别名模板，例如：

template这些比在字段中为您提供返回值的旧类型映射更容易使用，::type因为即使您的类型参数依赖于本地上下文，您也不需要通知编译器结果是一个类型。

实际上，您typename从使用位置提升到using别名。

有什么等效的东西可以用来摆脱产生的无关templates 吗？

假设您有一个元函数，其输出是类或别名模板而不是类型。当前的方法是这样的：

然后我们可以像这样使用它：

返回类型中的那个额外template关键字的存在是为了消除我的元函数的返回值的歧义，这是我想要消除的。

有没有办法向编译器表明元计算的结果是 C++11 或 C++1y 中的另一个别名或类模板，而不template在调用位置使用关键字？

IE：

甚至

在 C++11 之前我用过boost::bind很多boost::lambda。bind一部分进入了标准std::bind库（现在，我几乎不使用std::bind，因为我几乎可以用 C++ lambda 做任何事情。我能想到一个有效的用例std::bind：

对应的 C++14 将是

更短更简洁。（在 C++11 中，由于 auto 参数，这还不起作用。）是否有任何其他有效std::bind的用例可以击败 C++ lambdas 替代方案，或者std::bind对于 C++14 来说是多余的？

I tried to implement the C++14 alias template make_integer_sequence, which simplifies the creation of the class template integer_sequence.

To implement make_integer_sequence we need a helper structure make_helper.

Implementing make_helper isn't too difficult.

To test make_integer_sequence I made this main function:

I compiled the program with GCC 4.8.0, on a quad-core i5 system with 8GBs of RAM. Successful compilation took 4 seconds.

But, when I changed the GEN macro to:

The compilation was unsuccessful and outputted the error message:

virtual memory exhausted.

Could somebody explain this error and what caused it?

EDIT:

I simplified the test to:

I then successfully compiled with GCC 4.8.0 -ftemplate-depth=65536.

However this second test:

Did not compile with GCC 4.8.0 -ftemplate-depth=65536, and resulted in the error:

virtual memory exhausted.

So, my question is, how do I decrease template deep instantiation?

Regards, Khurshid.

Clang 3.3 支持一些 C++14 特性，比如成员初始化器和聚合。-std=c++11但是，即使使用switch ，我也无法编译此代码。

我究竟做错了什么？

我使用继承自的类std::system_error进行错误处理，并且我想控制what()调用时返回的内容。原因：标准（C++11 和草稿 C++1y CD - N3690，下面的 § 引用属于后者）没有指定返回的字符串what()应该是什么样子，它只是在 §19.5 中给出了注释.6.2 (14)：

注意：返回的 NTBS 可能是what_arg + ": " + code.message(). ——尾注

所以它应该被认为是依赖于实现的。（顺便说一句，不应该code().message()代替code.message()吗？）

what()所以，问题是：如果我想要符合标准并且不依赖于实现（即想要可移植），我该如何精确定义返回的字符串？

对于那些喜欢代码的人：

好的，我不喜欢的一个简单的解决方案可能如下：

既然std::exception::what()是虚拟的，它就可以工作，但是有没有更优雅的方法而不使用任何实现细节？我不喜欢存储两个字符串的想法：一个std::system_error在my_what.

问题的根源：std::runtime_error——恰好是 std::system_error 的父类——在 §1.9.2.6 (3) 中有一个确切的要求，即构造函数的后置条件：

其中，std::system_error在 §19.5.6.2 (2) 中变为以下内容：

有没有人知道为什么标准如此努力地包含code().message()在内what()？请注意，它code()返回错误代码对象，因此任何人都可以随时将其包含code().message()在字符串中（即使在捕获此类异常时）。

如果 的 要求与std::system_error的 相同std::runtime_error，我可以写：

有没有优雅便携的解决方案？

更新：下面的许多评论都指出错误消息是实现定义的。我明白，我只想格式化返回的字符串what()，我不想在所有系统上都逐字节等效。想想我想记录它或将它传递给第三方，它应该遵循一些固定的格式（这不是标准所建议的）。

UPDATE2：我相信 std::system_error 不仅适用于操作系统或 STL 错误。我可以（并且假设）从中派生出我自己的类并将它们用于错误报告。如果我正在编写低级 API 怎么办？顺便问一下，为什么禁止在高级 API 中使用它？

如果我在我的 API 的错误处理部分将所有参数传递给它的构造函数，则不涉及实现定义（即未知）的错误字符串，但我仍然无法在不复制数据的情况下对其进行格式化。