问题标签 [c++11]

m_MAX 和 ask() 由 run() 使用，否则不应公开。如何/应该如何做到这一点？

在 2009 年 7 月的法兰克福 C++0x 会议上，决定从 C++0x中删除概念。就个人而言，我很失望，但我宁愿拥有一个可实现的 C++0x 而不是没有 C++0x。他们说他们将在以后添加。

您对此决定/问题有何看法？它将如何影响您？

您可能听说过，C++ 标准委员会的最后一次会议投票决定从下一个 C++ 标准中删除概念。当然，这会影响其他功能，并且似乎会再次打开标准。如果是这样，您认为应该删除（或添加）哪些其他功能，为什么？

链接：

删除概念——Danny Kalev（关于删除概念的决定）

简化概念的使用——Bjarne Stroustrup（关于现在的概念问题）

长杆越来越长——Martin Tasker（关于如果必须修复概念对 C++0x 时间表的影响）

C++0x“删除概念”决定- Stroustrup 关于 Dobbs 博士的问题

旅行报告：退出概念，大约 18 个月后的 ISO C++ 最终草案- Herb Sutter

概念在 C++0x 岛上获得投票- Jeremy Siek 捍卫当前的概念规范

法兰克福发生了什么？- Doug Gregor on C++Next（关于概念的历史和删除）。

我在 Windows 上使用 tdm-mingw g++ 4.4.0 中的 -std=gnu++0x 参数构建了一个应用程序。

它使用了一个 ofstream 对象，当我构建时，它给出了以下链接错误：

使用默认的旧标准时，它可以正确构建。

这是唯一的错误，尝试与 -lstdc++ 链接没有帮助。以前有人经历过吗？我可以得到任何建议吗？

编辑：我正在创建一个这样的 ofstream 对象：

它编译得很好，但没有得到链接。

我正在尝试编写一些最初依赖于 Boost.Regex 的可移植 C++ 库代码，然后在编译器支持它时移至 TR1，并在事情从 std::tr1 命名空间移出后最终移至 C++0x 规范到标准。这是我想用预处理器做的一些伪代码：

当然，所有这些都需要在预处理器指令中，但如果我知道如何完成它，我就不会在这里问了。:)

概念（即最近从 C++0x 标准中删除的概念）与 Java 等语言中的接口有何不同？

如何迭代元组（使用 C++11）？我尝试了以下方法：

但这不起作用：

错误 1：抱歉，未实现：无法将 'Listener ...' 扩展为固定长度的参数列表。
错误 2：i 不能出现在常量表达式中。

那么，我如何正确地迭代元组的元素呢？

（序言：我是 C++0x 游戏的后期追随者，最近关于从 C++0x 标准中删除概念的争议促使我更多地了解它们。虽然我明白我所有的问题都是完全假设的——只要概念在未来一段时间内都不是有效的 C++ 代码，如果有的话——我仍然有兴趣了解更多关于概念的知识，特别是考虑到它如何帮助我更全面地理解最近决定背后的优点以及随之而来的争议）

在阅读了一些关于 C++0x （直到最近）提出的概念的介绍性材料之后，我无法将我的思想集中在一些句法问题上。事不宜迟，以下是我的问题：

1) 支持特定派生概念的类型（隐式地，通过 auto 关键字，或显式地通过 concept_maps）是否也需要独立地支持基本概念？换句话说，从另一个概念（例如concept B<typename T> : A<T>）推导出一个概念的行为是否隐含地包含一个“不可见的”需求语句（在 B 内requires A<T>;）？混淆来自关于概念的维基百科页面，该页面指出：

与类继承一样，满足派生概念要求的类型也满足基概念要求。

这似乎是说一个类型只需要满足派生概念的要求，而不必满足基本概念的要求，这对我来说毫无意义。我知道维基百科远不是一个确定的来源；上面的描述只是一个糟糕的选择吗？

2）列出类型名的概念可以是“自动”吗？如果是这样，编译器将如何自动映射这些类型名？如果不是，在其他情况下在概念上使用“自动”是无效的吗？

为了澄清，请考虑以下假设代码：

这些类中的任何一个都与 SomeType 匹配吗？或者对于涉及类型名的概念是否需要一个概念映射？

3）最后，我很难理解允许定义什么公理。例如，我能否有一个概念定义一个逻辑上不一致的公理，例如

那会做什么？这甚至有效吗？

我很感激这是一组很长的问题，所以我提前感谢你。

我想知道人们如何在编码风格方面使用 C++0x lambda。最有趣的问题是在编写捕获列表时要做到多彻底。一方面，该语言允许显式列出捕获的变量，并且通过“显式优于隐式规则”，因此进行详尽的列表以清楚地说明意图是有意义的。例如：

另一个论点是，由于 ref-captured locals 的生命周期不会仅仅因为它们被捕获而改变（因此 lambda 很容易最终引用一个生命周期早已结束的局部变量），因此显式捕获有助于减少此类错误并追踪他们。

另一方面，该语言还特意提供了一种快捷方式来自动捕获所有引用的本地变量，因此很明显它是打算使用的。并且可以声称，对于上述示例，即使使用自动捕获也会发生什么，并且 lambda 的生命周期不会超过周围的范围，因此没有理由不使用它：

显然，这不必是全有或全无，但必须有一些基本原理来决定何时自动捕获以及何时明确地进行捕获。有什么想法吗？

同样的另一个问题是何时使用 capture-by-copy - [=]，何时使用 capture-by-reference - [&]。Capture-by-copy 显然更安全，因为没有生命周期问题，因此有人可能会争辩说，只要不需要改变捕获的值（或从其他地方查看对其所做的更改），就应该默认使用它，并捕获 -在这种情况下，引用应该被视为（可能为时过早的）优化，仅在明显产生影响的情况下应用。

另一方面，按引用捕获几乎总是更快（特别是因为它通常可以优化到一个副本，如果后者实际上更快，对于小类型和内联模板函数，如大多数 STL 算法），并且是如果 lambda 永远不会超出其范围（这也是所有 STL 算法的情况），则安全，因此在这种情况下默认为按引用捕获是一种微不足道且无害的优化，不会造成伤害。

你觉得呢？你有没有什么想法？

来自Dobbs 博士：

概念本应成为 C++0x 的核心新特性

即使在削减“概念”之后，下一个 C++ 标准也可能会延迟。可悲的是，不会有 C++0x（除非您计算 C++03 中的小修正）。我们必须等待 C++1x，并希望 'x' 是一个低位数字。有希望是因为 C++1x 现在功能完整（除了一些国家标准机构有效地坚持标准正式提案中存在的某些功能的可能性）。剩下的“全部”就是解决突出的技术问题和评论的大量工作。

大约在 1997 年到 2000 年，我处于 ​​MT 和 MP 安全 C++ 编程的前沿。我们必须自己做很多事情。从那以后的 9 年里，该标准没有解决并发问题，这有点令人震惊。

那么有什么大不了的呢？