问题标签 [variadic-templates]

最近，在 gcc-trunk 源代码中实现了“用户定义的文字”。请告诉我，我是否正确理解我不能为可变字符模板定义“用户定义的文字”？

向上。

我不明白为什么允许这种表达方式：

这个是不允许的：

?

重点是什么？

向上。 这是因为模棱两可吗？

谢谢。

假设您要编写一个函数，该函数将不透明的句柄传递给未知类型的函数（例如，包含具有商定名称的函数的结构的名称），并将参数转发给该函数。

在非可变情况下，为简单起见考虑单参数函数，有两种方法可以做到这一点：您可以让转发函数接受任意类型的参数，并尝试使用它调用转发函数，编译器会抱怨在模板扩展期间，如果结果不兼容；或者您可以使用 decltype 和各种其他机制来确定转发函数期望的参数类型，并明确要求该类型的参数。我不知道这些是否有任何公认的术语，所以我将称它们为“通过”和“预先”。

pass through 方法直接泛化为具有任意数量参数的函数，但 prefront 方法没有。

问题是不允许参数包是独立的，只能作为模板参数，如果你将它们包装在一个封闭的模板中，就无法将它们解包并解包，只能通过模式匹配。

“预先”具有一些优点，例如更好的自文档化，以及对类型推断的更好支持（up_front<T> 本身可以被 decltyped）。有没有办法让它在可变参数的情况下工作？（你当然可以使用 std::tuple，但这很不令人满意。）

这个问题是因为这个而被问到的。

C++11 允许你为数字文字定义这样的文字：

这意味着这503_suffix将成为<'5','0','3'>

这很好，虽然它的形式不是很有用。

如何将其转换回数字类型？这将<'5','0','3'>变成一个constexpr 503. 此外，它还必须适用于浮点文字。<'5','.','3>会变成int 5或float 5.3

在上一个问题中找到了部分解决方案，但它不适用于非整数：

可能重复：
使用带有可变参数模板函数的 decltype 的尾随返回类型

我收到此编译器错误：

对于这个sum.cpp：

我尝试了多种声明此功能的方法。这只是 gcc 4.6.1 的问题吗？

编辑：这是我最终选择的，因为我不太信任::std::common_type模板。它仍然有一个问题，它会+从右到左而不是从左到右绑定。这可能会导致非交换+运算符出现问题。不过，这并不难解决：

所以说我这样定义一个元组：

考虑到 Tuple 的实例变量可以有未定义的数量，如何定义和访问实例变量？

所以，我使用可变参数模板制作了一个简单的元组类......

我将如何制作一个有效的 get 方法/辅助函数？我正在使用的当前导致编译器期望在空元组中定义一个 get 。

这是代码：

谢谢你的帮助！

我正在尝试使用 Visual C++ 11 构建 googletest，但以下代码会导致错误

这是一个错误文本：

还有utility-file的第72行：

有什么问题std::tuple以及如何解决？

（顺便说一句：我尝试更改std::tr1::tuple为未成功std::tuple）

在 C++11 中，可以创建一个函数，该函数在编译时使用 constexpr 返回内置一维数组的大小（元素数）。下面的例子：

这是 ARRAY_SIZE 和类似的宏 imo 的绝佳替代品。

但是，这只会返回内置多维数组的最重要维度的大小。

我使用以下函数来确定内置二维数组的大小：

理想情况下，拥有一个返回具有任意维数的内置数组大小的函数会非常有用。我认为可变参数模板可能会有所帮助，但由于只传递了一个参数，因此我看不到解包模板参数的方法。这样的功能可能吗？

提前致谢。

考虑以下类模板“X”及其部分特化。

我怀疑 X<int> 是模棱两可的。这是因为：

很明显#2 和#3 都比#1 更专业，现在比较#2 和#3。根据14.5.5.2，我们来考虑以下#2'和#3'哪个更特化。

根据14.8.2.4，第一步是使用#2'作为参数模板和#3'作为参数模板的模板参数推导。给定唯一的参数类型是 X<A1>，推导出的 T1 是 A1，Types 是空的。

第二步是使用 #3' 作为参数模板和 #2' 作为参数模板完成的。给定唯一的参数类型是 X<A1, Args...>，根据 14.8.2.5/9（注意这一段最近由 N3281 修订），Args 被简单地忽略，推导出的 T1 为 A1，并且参数推导成功。

最终，双向论证推演成功。所以#2 和#3 一样专业。总之，X<int> 是模棱两可的。

我的问题是：“我的解释正确吗？”

如果这个解释是正确的，那么 20.9.7.6/3 中 'std::common_type' 的定义是不合适的。

当使用 common_type<A, B> 时，#3 和 #4 是不明确的。

注意：在第一个示例中，GCC 4.7.0（快照）和 Clang 3.0 选择 #2。但是，这些编译器非常不可靠，以至于它们不遵循 N3281 的其他更改。