如果给定的weak_ptr有效，我正在尝试创建一个在调用时执行 lambda/std::function 的辅助函数。目前以下代码有效，但不幸的是，它需要我定义模板参数。我正在寻找一种通过自动模板参数推导来做到这一点的方法。

理想情况下，我想std::function <void(ArgumentTypes...)>用通用模板参数替换FunctorType，但是我不确定如何从FunctorType. 上面的代码有效，下面的代码是理论上的：

有没有办法做这样的事情？

鉴于所有三个函数，这个调用是模棱两可的。

删除f( int )会导致 Clang 和 GCC 都更喜欢右值引用而不是左值引用。但是，删除任一引用重载会导致与f( int ).

重载解决通常是按照严格的偏序来完成的，但int似乎等同于两个互不等同的东西。这里有什么规则？我似乎记得有关此的缺陷报告。

在未来的标准中是否有机会int &&被优先考虑？int引用必须绑定到初始化程序，而对象类型不受限制。T因此，在and之间重载T &&可能实际上意味着“如果我已获得所有权，则使用现有对象，否则复制。” （这类似于纯值传递，但节省了移动的开销。）由于这些编译器当前工作，这必须通过重载T const &和T &&显式复制来完成。但我什至不确定这是否是严格的标准。

“具有自动存储持续时间的运行时大小的数组（N3639）”的（已接受）提案断言

堆栈溢出变得更有可能，特别是如果大小取决于外部输入并且没有正确检查。因此，某些环境可能会禁止使用该功能。使用静态分析工具可以轻松执行此类禁止。

如果需要分析器实现完整的 C++ 编译器，我认为执行起来并不容易。

考虑以下代码：

在我看来，每次使用都需要重复分析array_user<T>并考虑：

• traits<T>在使用点可发现的适用专业化array_user<T>
• 是否traits<T>::omega是编译时常量表达式（通过constexpr或 C++03 方法，例如enum）
• 的类型traits<T>::omega
• f()（在使用点array_user<T>并且可能通过 ADL 找到）的适用过载是否是constexpr

我错过了什么吗？是否可以在不经过完整编译的情况下强制执行这样的限制？

可以以这样一种方式编写代码来简化不使用运行时边界的验证吗？

在 Eric Niebler 的 Proto-0x 演讲结束时，有一个关于C++1y特性的讨论。在讨论普通函数的返回类型推导时，他说，（我想使用当前的C++1y规范），他将无法对普通函数使用返回类型推导（这将允许他替换一些他的RETURN try_call 聪明）。我希望我理解了这一点。如果我没有，请纠正我。

可悲的是，视频中没有捕捉到这一断言背后的理由（我几乎听不到任何声音）。我能听到的唯一原因是函数没有被推断为noexcept. 但似乎还有另一个更重要的原因。

有谁知道原因或能够转录讨论？

使用新的宽松 C++14 constexpr 规则，编译时编程变得更具表现力。我想知道标准库是否也会升级以利用。特别是 , , std::initializer_list,和似乎是被标记为批发的主要候选者。std::pairstd::tuplestd::complexstd::bitsetstd::arrayconstexpr

问题：

• 现在将标记标准库的哪些部分constexpr？
• 还可以标记哪些其他部分constexpr？
• 例如，为什么没有来自<cmath>和<algorithm>标记的功能constexpr？
• 是否有向后兼容的理由不这样做？

在 C++11 中编写递归 lambda 函数有一个经常重复的“技巧”，如下所示：

（例如C++0x 中的递归 lambda 函数。）

但是，这种技术有两个直接的缺点：对象的目标std::function<Sig>（通过引用捕获）绑定到一个非常特定的std::function<Sig>对象（此处为factorial）。这意味着生成的仿函数通常不能从函数返回，否则引用将悬空。

另一个（虽然不那么直接）的问题是使用std::function通常会阻止编译器优化，这是在其实现中需要类型擦除的副作用。这不是假设的，可以很容易地进行测试。

在递归 lambda 表达式真的很方便的假设情况下，有没有办法解决这些问题？

考虑以下取自N3650的示例：

我可能遗漏了一些东西，但如果我理解async得await很好，当效果等同于写作时，用上面的例子展示这两个结构的有用性有什么意义：

read().get()和调用都是write().get()同步的？

我查看了通用 lambda并且无法理解 - 为什么要保留类型声明？为什么不 (x, y)呢？如果编译器厂商要(auto a, auto b)支持simple 有没有问题(a, b)？

是否可以推断 CRTP 基类中模板化成员函数的返回类型？

虽然推断参数类型效果很好，但它会因返回类型而失败。考虑下面的例子。

这会产生以下错误：

我的直观假设是，如果编译器能够推断int参数的类型f，它也应该适用于 return bool，因为这两种类型在模板实例化时都是已知的。

我尝试使用尾随返回类型函数语法，但后来找不到要放入的工作表达式decltype。

编辑 1

对于函数具有一个或多个模板化参数的情况，Dietmar Kühl 提供了一种基于使用间接层延迟模板实例化的解决方案。不幸的是，当基类函数没有任何参数时，这不起作用，如下所示：

使用相同技术的尝试失败，因为不存在依赖类型。如何处理这种情况？

编辑 2

正如 Johannes Schaub 所指出的，C++11 具有默认模板参数，因此始终可以g依赖于任意类型，然后应用 Dietmar 的解决方案：

编辑 3

这个问题在 C++14 中已经不存在了，因为我们对普通函数进行了返回类型推导，所以我们可以简单地写：

在浏览 C++14/C++1y (n3690) 的草稿时，我注意到在第 21.7 节中引入了basic_string文字后缀：

我的问题是：

• basic_string文字是否有可能在运行时更快？
• 我的“天真”实施完全错误吗？
• ROM 中的数据布局可以与basic_string文字不同，或者在编译时与运行时有任何其他差异吗？

背景

我知道这允许直接使用这样的字符串文字：

但是，与依赖转换构造函数 string(const char*)相比，这有什么优势呢？

“旧”代码如下所示：

据我所见，实现operator "" s()基本上是这样的：

因此，只需使用相同的 c'tor。我的猜测是，这必须在运行时完成，我错了吗？

编辑：正如Nicol Bolas在下面正确指出的那样，我的示例没有使用相同的构造函数，而是使用具有额外长度的构造函数——显然，这对构造非常有用。这给我留下了一个问题：编译器将字符串文字放入 ROM 或在编译时类似的东西是否更好？