在 2009 年 7 月的法兰克福 C++0x 会议上，决定从 C++0x中删除概念。就个人而言，我很失望，但我宁愿拥有一个可实现的 C++0x 而不是没有 C++0x。他们说他们将在以后添加。
您对此决定/问题有何看法？它将如何影响您？
问问题
1065 次
9 回答
8
就我个人而言，我对删除并不太不满意，因为概念的目的主要是改善编译时错误消息，正如概念提案的共同作者之一 Jeremy Siek 所写（http://lambda-the-ultimate .org/node/3518#comment-50071）：
虽然 Concepts 提案并不完美（C++ 的任何扩展真的是完美的吗？），它会为该语言提供一个非常有用和有用的扩展，这个扩展将大大减少当前模板库用户的臭名昭著的错误消息被困扰。
当然，概念不仅仅是使编译器能够给出更短的错误消息，但目前我认为我们都可以没有它们。
编辑：Herb Sutter 也在他的博客上写道：
问：这不是 C++0x 的一大特色吗？
答：不会。概念会很棒，但对于大多数用户来说，概念的存在与否不会影响他们使用 C++0x 的体验，除了错误消息的质量。
问：概念不就是为语言增加主要的新表达能力，从而使主要的新程序或编程风格成为可能吗？
答：没有。概念几乎完全是关于获得更好的错误消息。
于 2009-07-22T07:51:26.453 回答
6
我很期待他们。主要是为了在编译失败时更好地报告错误。没有什么比阅读 1000 个字符串更能找出你的愚蠢错误了。
于 2009-07-20T18:01:32.573 回答
4
看到他们从名单上掉下来我很难过。
就我个人而言，我喜欢我用来遵循已知接口的类型，无论是原语、结构还是类。这样我就知道如何使用该类型以及我必须实现什么来提供该类型。
这一切都可以通过标准的面向对象编程轻松实现。然而，在我看来，虽然技术上的泛型编程是强类型的，但它失去了类型提供 OO 的接口概念。事实上，泛型编程有点像动态类型，但从接口的角度来看是在编译类型时解决的。
例如，我将一个迭代器传递给一个算法，它必须提供一些运算符，但没有接口来指定这些运算符应该做什么，或者他们的合同是什么（只有文档）。如果您有operator++()并且operator*()它会编译，但它不会为您提供与接口在 OO 中为您提供的相同类型保证。
对我来说，Concepts 为泛型编程带来了类型，为 OO 带来了确定性接口，更好的编译只是一个奖励。
我知道我们都是 c++ 程序员，我们非常聪明，我们阅读文档并了解运算符重载和泛型编程的微妙之处。但是当语言提供了我可以依赖的保证并且编译器可以测试时，我可以花更多的脑力来解决我得到报酬来解决的问题。
于 2009-07-22T11:34:30.777 回答
2
我还没有过多地参与概念。然而，我注意到的是，它们通常非常冗长。我想我不希望它们出现在 STL 库中。我已经知道这个库，我可以轻松解析任何编译时错误。不需要概念。但是，概念会很好地描述我自己的课程，以便同事可以更快地学习它们并避免误用。据我所知，每个概念都是一个约束，它限制了类型的使用。当创建其他人必须学习的新界面时，这会很好。
于 2009-07-21T20:30:32.640 回答
1
我非常喜欢概念！通过外部定义（概念映射）使非常不同的类型表现相同的可能性是一个非常强大且有用的功能（特别是因为它发生在编译时，因此不会影响运行时性能）。
我认为它比直接在类型中实现所有有用的功能并通过像.NET 中所做的接口访问它们更强大和更好。这不允许以后的可扩展性（好吧，.NET 知道自 3.0（或 3.5，不确定）以来的扩展方法，但不一样）。
改进错误消息是概念带来的另一个（也是原始的）巨大改进。
但是当我阅读概念时，我的第一个想法是：这将需要很长时间，直到 GCC 和 MSVC 支持它。
因此，我认为将其从即将发布的标准中删除是有意义的。但我希望的是包含概念的后 C++0x 标准的特性的固定协议。这将允许编译器供应商更好地为 C++2x 标准做准备。
所以我真的希望我们能在不远的将来看到概念。
于 2009-07-22T19:57:31.977 回答
1
我认为他们做出了正确的决定。我很想看到一个高质量的概念实现添加到语言中，但是规范的方向是错误的，给用户带来了太多的负担来明确指定概念图。Stroustrup 的论文确实提出了一些解决方案，但我认为这将是一个相当激进的变化，在这个过程的后期。并且没有编译器对其进行测试。
总而言之，最终指定的概念将是一个很大的倒退，阻碍了泛型编程，并可能分裂 C++ 社区，一大群程序员坚持使用 C++03。
就我所见，由 Stroustrup 提出的“修复”的概念是可以的，但如此快地采用这些更改是有风险的。（而且我不相信这不会造成进一步的延误。）
老实说，我很高兴看到他们安全行事并暂时将其删除。直到现在，我们在没有概念的情况下幸存下来，我可以在没有概念的情况下再活 5 年。
于 2009-07-24T19:04:18.257 回答
1
这是非常可悲的。将概念引入 C++ 将使其类型系统几乎达到与 Haskell 类型类相同的功能水平，而且它会非常棒 - 一种针对速度优化的语言，让你做任何你想做的事，但除非你使用逃生口，否则严格类型安全（同时仍然保持快速！）。它还应该解决长期存在的问题，即 STL 和 Boost（以及一般的模板库）由于 C++03 模板的“编译时鸭子类型”性质松散而难以使用，以及随之而来的编译器问题错误报告。
于 2009-07-24T19:24:59.743 回答
1
我也认为这是一个糟糕的电话，并且C++0x对于删除来说会更糟，但是刚刚读完 Stroustrup 的简化概念的使用，我改变了主意。我不知道概念提案有那么复杂，我认为在添加到语言之前会经过深思熟虑是一件好事。尽管 Stroustrup 鼓吹保持概念，但他的文章使我相信，就目前的情况而言，概念弊大于利，即使 BS 提出了一个解决方案，我担心它可能会仓促，并且尚未理解所有含义。
于 2009-07-29T11:30:12.027 回答
1
我很伤心。
我检查了ConceptGCC，它很棒！我已经使用它编写了一些简单的库，并且我看到了一些缺点，例如要编写更多代码，或者在思考概念抽象的力量时有些麻烦。std 概念库确实会产生问题，因此在标准中包含这样一个只是误解。我认为即将到来的标准应该只是标准化概念语法，并提供一些如何使用它的提示。
于 2009-07-29T21:42:43.613 回答