C ++ 0X概念已经走了。哪些其他功能也应该去？ [英] C++0X Concepts are gone. Which other features should go too?

问题描述

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

As you may have heard, the last meeting of the C++ standards committee voted to remove concepts from the next C++ standard. Of course, this will affect other features and would seem to throw the standard wide open again. If that is the case, which other features do you think should be stripped away (or added), and why?

链接：

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

Removal of Concepts -- Danny Kalev (on the decision to remove concepts)

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

Simplifying the use of Concepts -- Bjarne Stroustrup (on the problems with concepts as they look now)

长杆取得更长 - Martin Tasker（如果概念必须固定，对C ++ 0x的进度的影响）

The Long Pole Gets Longer -- Martin Tasker (on the impact to the schedule for C++0x if concepts have to be fixed)

C ++ 0x删除概念决定 - Stroustrup对Dobbs博士的问题

The C++0x "Remove Concepts" Decision - Stroustrup on the issue on Dr. Dobbs

旅行报告：退出概念，最终ISO C ++草稿〜18个月< a> - Herb Sutter

Trip Report: Exit Concepts, Final ISO C++ Draft in ~18 Months - Herb Sutter

概念获得投票关闭C ++ 0x岛 - Jeremy Siek保护当前的Concepts spec

Concepts Get Voted Off The C++0x Island - Jeremy Siek defending the current Concepts spec

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

What Happened in Frankfurt? - Doug Gregor on C++Next (on the history and removal of Concepts).

推荐答案

当然，这会影响其他
功能，
标准再次打开。

Of course, this will affect other features and would seem to throw the standard wide open again.

很难。他们仍然希望很快完成标准，这是删除概念的主要原因之一。使它开放到无关的变化只会抛弃他们通过倾覆概念获得的一切。

Hardly. They still want to wrap up the standard soon, which is one of the main reasons for removing concepts. Making it "wide open" to unrelated changes would just throw away everything they gained by ditching concepts.

无论如何....在剩余的C ++ 0x添加，不能想到我想要删除的任何东西。我同意他们对于概念的决定。 Stroustrup的论文真的概述了一些严重的问题，目前的概念规范肯定会简化模板错误消息，但它会这样做通过大大降低通用编程的有用性 - 我不愿意支付的价格。

Anyway.... Of the remaining C++0x additions, I can't think of anything else I'd want to remove. I agree with their decision regarding concepts though. Stroustrup's paper really outlined some serious problems, The current specification for concepts would admittedly simplify template error messages, but it would do so by dramatically reducing the usefulness of generic programming -- a price I'm not willing to pay.

当我第一次阅读那篇论文时，它吓到了我，因为我认为在对规范进行严重修改的过程中太迟了。原来是不是，委员会愿意采取戏剧性的行动。

When I first read that paper, it scared me, because I assumed it was too late in the process for making serious changes to the spec. Turns out it wasn't, and the committee was willing to take dramatic action.

但除此之外，我认为C ++ 0x是在良好的形状。其余的新功能都是值得的。

But apart from this, I think C++0x is in good shape. The remaining new features all look worthwhile.

当然，有很多现有的功能，我想删除。主要是向量< bool> 专业化。还有其他流行的功能的例子没有解决（导出关键字，异常规范），但矢量专门化是唯一的一个，不能被忽略。只要我们不尝试导出模板，关键字存在（并且不是由编译器实现）并不重要，我们可以避免使用异常规范，但每次我们需要一个bool的向量，我们被愚蠢的过早优化咬住了，陷入了当前的标准。

Of course, there are plenty of existing features I'd love to remove. Primarily the vector<bool> specialization. There are other popular examples of features that didn't work out (the export keyword, exception specifications), but the vector specialization is the only one of them that can't be ignored. As long as we don't try to export templates, it doesn't matter that the keyword exists (and isn't implemented by compilers), and we can just refrain from using exception specs, but every time we need a vector of bools, we're bitten by the stupid premature optimization that slipped into the current standard.

不幸的是，似乎他们已经放弃了删除它。 （最后我检查，它甚至不被弃用）。

Unfortunately, it seems like they've given up on removing it. (Last I checked, it wasn't even deprecated).

当然，大量的旧C cruft也可以被切掉，但最近，我发现，一个变化，我真的爱看到是......切断Iostreams库。

Of course, plenty of old C cruft could be ditched too, but recently, I've discovered that the one change I'd really love to see is...... ditching the Iostreams library. Toss it out, and build a new STL-style I/O library based on generic programming.

当前的OOP风格的Iostreams库是丑陋，缓慢，过于复杂和不灵活的。有太多的voodoo涉及到定义新的流，太少的标准流类型涉及，太少的灵活性（使我意识到如何有限的库是的问题是，我需要从字符串中提取一个浮点容易使用stringstream ，但是如果你需要经常做，你不想每次复制输入字符串（如stringstream） - 在现有的迭代器范围工作的流 - 或者一个原始数组，甚至？ ）

The current OOP-styled Iostreams library is ugly, slow, overcomplicated and inflexible. There's too much voodoo involved in defining new streams, too few standard stream types involved, too little flexibility (the problem that made me realize how limited the library is, was that I needed to extract a float from a string. Easy to do with stringstream, but if you need to do it often, you don't want to have to copy the input string every time (as the stringstream does) -- where's the stream that works on an existing iterator range? Or a raw array, even?)

抛出IO流出，开发现代替换，C ++将大大改进。

Throw IOstreams out, develop a modern replacement, and C++ will be vastly improved.

也许对字符串类做一些事情。它的工作原理是ok'ish，因为它是现在，但真的，什么与巨大的成员函数的数量？大多数人会更好地工作，更一般的，作为自由功能。标准库中的太多都特别依赖于字符串类，当它原则上可以使用任何容器，甚至是迭代器（ std :: getline ，我在看你）

And perhaps do something about the string class as well. It works sort of ok'ish as it is now, but really, what's with the huge number of member functions? Most of them would work better, and be more general, as free functions. Too much of the standard library relies specifically on the string class, when it could in principle work with any container, or even an iterator (std::getline, I'm looking at you)

这篇关于C ++ 0X概念已经走了。哪些其他功能也应该去？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！