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.
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.
But apart from this, I think C++0x is in good shape. The remaining new features all look worthwhile.
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).
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.
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?)
Throw IOstreams out, develop a modern replacement, and C++ will be vastly improved.
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++ 最终脱离 C。不再有预处理器，不再有头文件。 我基本上想要 D，但没有 D 附加的所有东西，使用 STL。
Personally, I want C++ to finally break away from C. No more pre-processor, no more header files. I basically want D, but without all the stuff that D tacks on, using the STL.
None, I think the rest of the draft was great - a large number of very small pieces that can be correctly implemented independently, allowing vendors to evolve toward complete support and allowing users to take a "shopping list" approach.
Quite a different situation with contracts, as they were like a whole new parallel type system and would have been very likely to have led to different compilers ending up with their own backward compatibility problems, very similar to CSS in web browsers.
// lazy evaluation of vector addition
template<typename T, class V1, class V2>
class vector_add {
V1& lhs_;
V2& rhs_;
public:
T operator[](size_t n) const
{ return lhs_[n] + rhs_[n]; }
// If used by auto or decltype perform eager creation of vector
std::vector<T> operator auto() const
{
if (lhs_.size() != rhs_.size())
throw std::exception("Vectors aren't same size");
std::vector<T> vec;
vec.reserve(lhs_.size());
for (int i = 0; i < lhs_.size(); ++i)
vec.push_back(lhs_[i] + rhs_[i]);
return vec;
}
There are two things I think should be added to C++0x, I've thought of both these myself and then found that others have suggested them before but it doesn't seem like they're going to happen.
1. Defaulting Move Constructors and Move Assignment Operators
Writing a move constructor is a manual and error prone activity, if a member is added it must be added to the move constructor and assignment operators and std::move must be used religiously. That's why I think these functions should be defaultable.
// lazy evaluation of vector addition
template<typename T, class V1, class V2>
class vector_add {
V1& lhs_;
V2& rhs_;
public:
T operator[](size_t n) const
{ return lhs_[n] + rhs_[n]; }
// If used by auto or decltype perform eager creation of vector
std::vector<T> operator auto() const
{
if (lhs_.size() != rhs_.size())
throw std::exception("Vectors aren't same size");
std::vector<T> vec;
vec.reserve(lhs_.size());
for (int i = 0; i < lhs_.size(); ++i)
vec.push_back(lhs_[i] + rhs_[i]);
return vec;
}
对我来说，添加到语言中的概念最重要的是编译错误的表达性表述，这是当今 C++ 受到最批评的地方之一。
安息吧概念。
To me the problem is not what other features should be stripped away, but how complex will other features be after concepts have been removed. That and how much longer will it take for the rest of the features to be rephrased without concepts.
A lot of features assumed that concepts would be accepted into the language and the wording is expressed in terms of concepts. (I wonder if any proposed feature depends on concepts).
I also wonder how other libraries will evolve (think boost::type_traits) to take the niche left by concepts. Part of what concepts provided can be implemented (even if in a more cumbersome way) in terms of traits applied to the type arguments.
To me, the most important thing that concepts added to the language was an expressive formulation of compilation errors, which is nowadays one of the places where C++ is most criticized.
Do whatever you want with concepts, but for god's sake keep threads and atomics, we absolutely need them. Perhaps add thread groups and support for cooperative threads a.k.a. fibers. IMO these are far more important than concepts, because everyone uses/will soon be using threads.
There's already a common and accepted idiom for acheiving the same effect (declare the function in question as private). I think this feature will just generate lots of 'I used =delete to remove a base class function from my derived class, but it can still be called using a base class pointer' questions.
Not to mention confusing people between the (now) two meanings of the delete keyword.
发布评论
评论（9）
几乎不。 他们仍然希望尽快完成标准，这是删除概念的主要原因之一。 使其对不相关的变化“完全开放”只会抛弃他们通过放弃概念而获得的一切。
不管怎样......在剩下的 C++0x 添加中，我想不出还有什么我想删除的。 不过，我同意他们关于概念的决定。 Stroustrup 的论文确实概述了一些严重的问题，当前的概念规范无疑会简化模板错误消息，但这样做会大大降低泛型编程的实用性——这是我不愿意付出的代价。
当我第一次读到那篇论文时，我感到害怕，因为我认为对规范进行重大更改的过程为时已晚。 事实证明并非如此，委员会愿意采取戏剧性的行动。
但除此之外，我认为 C++0x 状况良好。 剩下的新功能看起来都值得。
当然，我想删除很多现有的功能。 主要是
vector专门化。 还有其他一些流行的功能示例没有发挥作用（导出关键字、异常规范），但向量专业化是其中唯一不可忽视的功能示例。 只要我们不尝试导出模板，关键字存在（并且编译器未实现）并不重要，并且我们可以避免使用异常规范，但每次我们需要一个布尔向量，我们被当前标准中愚蠢的过早优化所困扰。不幸的是，他们似乎已经放弃删除它了。 （上次我检查过，它甚至没有被弃用）。
当然，很多旧的 C 垃圾也可以被抛弃，但最近，我发现我真正希望看到的一个变化是……抛弃 Iostreams 库。 扔掉它，基于泛型编程构建一个新的STL风格的I/O库。
当前的 OOP 风格的 Iostreams 库丑陋、缓慢、过于复杂且不灵活。 定义新流涉及太多巫术，涉及的标准流类型太少，灵活性太少（让我意识到该库有多么有限的问题是我需要从字符串中提取浮点数。使用 stringstream 很容易做到，但是如果您需要经常这样做，您不想每次都复制输入字符串（就像 stringstream 那样）——适用于现有迭代器范围的流在哪里？或者甚至是原始数组？ ）
扔掉 IOstream，开发一个现代替代品，C++ 将得到极大的改进。
也许还可以对字符串类做一些事情。 它现在的工作方式还不错，但实际上，大量的成员函数是怎么回事？ 作为自由函数，它们中的大多数会工作得更好，并且更通用。 太多的标准库专门依赖于字符串类，而原则上它可以与任何容器一起工作，甚至可以与迭代器（
std::getline，我是看着你）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.
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.
But apart from this, I think C++0x is in good shape. The remaining new features all look worthwhile.
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).
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.
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?)
Throw IOstreams out, develop a modern replacement, and C++ will be vastly improved.
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++ 最终脱离 C。不再有预处理器，不再有头文件。 我基本上想要 D，但没有 D 附加的所有东西，使用 STL。
Personally, I want C++ to finally break away from C. No more pre-processor, no more header files. I basically want D, but without all the stuff that D tacks on, using the STL.
没有，我认为草案的其余部分很棒 - 大量可以独立正确实现的非常小的部分，允许供应商向完全支持发展，并允许用户采取“购物清单”方法。
合约的情况则完全不同，因为它们就像一个全新的并行类型系统，很可能导致不同的编译器最终出现自己的向后兼容性问题，与网络浏览器中的 CSS 非常相似。
None, I think the rest of the draft was great - a large number of very small pieces that can be correctly implemented independently, allowing vendors to evolve toward complete support and allowing users to take a "shopping list" approach.
Quite a different situation with contracts, as they were like a whole new parallel type system and would have been very likely to have led to different compilers ending up with their own backward compatibility problems, very similar to CSS in web browsers.
我认为有两件事应该添加到 C++0x 中，我自己也想到了这两件事，然后发现其他人之前已经建议过它们，但似乎它们不会发生。
1. 默认移动构造函数和移动赋值运算符
编写移动构造函数是一项手动且容易出错的活动，如果添加成员，则必须将其添加到移动构造函数和赋值运算符以及
std::move必须虔诚地使用。 这就是为什么我认为这些函数应该是默认的< /a>.编辑（2009-10-01）：看起来这是终究会发生。
2. 覆盖表达式模板的类型推导
表达式模板通常定义不应该直接使用的类型，一个典型的例子是
std::vector的返回值 operator[](size_type n) ，如果在此类对象上使用auto或decltype可能会发生意外行为。因此 类型应该能够说出什么类型它应该被推导为（或者使用
=delete语法防止推导）。向量加法的示例。
There are two things I think should be added to C++0x, I've thought of both these myself and then found that others have suggested them before but it doesn't seem like they're going to happen.
1. Defaulting Move Constructors and Move Assignment Operators
Writing a move constructor is a manual and error prone activity, if a member is added it must be added to the move constructor and assignment operators and
std::movemust be used religiously. That's why I think these functions should be defaultable.Edit (2009-10-01): Looks like this is going to happen after all.
2. Override Type Deduction for Expression Templates
Expression templates often define types that should not be used directly, a case in point is the return value of
std::vector<bool> operator[](size_type n), ifautoordecltypeare used on this kind of object unexpected behaviour may ensue.Therefore a type should be able to say what type it should be deduced to be (or prevent deduction using
= deletesyntax).Example for vector addition.
对我来说，问题不在于应该删除哪些其他功能，而在于删除概念后其他功能会变得多么复杂。 剩下的功能需要多长时间才能在没有概念的情况下重新表述。
许多功能都假设概念将被语言接受，并且措辞是用概念来表达的。 （我想知道是否有任何提议的功能取决于概念）。
我还想知道其他库将如何发展（想想 boost::type_traits）以占据概念留下的利基市场。 所提供的部分概念可以根据应用于类型参数的特征来实现（即使以更麻烦的方式）。
对我来说，添加到语言中的概念最重要的是编译错误的表达性表述，这是当今 C++ 受到最批评的地方之一。
安息吧概念。
To me the problem is not what other features should be stripped away, but how complex will other features be after concepts have been removed. That and how much longer will it take for the rest of the features to be rephrased without concepts.
A lot of features assumed that concepts would be accepted into the language and the wording is expressed in terms of concepts. (I wonder if any proposed feature depends on concepts).
I also wonder how other libraries will evolve (think boost::type_traits) to take the niche left by concepts. Part of what concepts provided can be implemented (even if in a more cumbersome way) in terms of traits applied to the type arguments.
To me, the most important thing that concepts added to the language was an expressive formulation of compilation errors, which is nowadays one of the places where C++ is most criticized.
R.I.P. concepts.
用概念做任何你想做的事，但看在上帝的份上保留线程和原子，我们绝对需要它们。 也许添加线程组并支持协作线程，即 Fiber。 在我看来，这些比概念重要得多，因为每个人都使用/即将使用线程。
Do whatever you want with concepts, but for god's sake keep threads and atomics, we absolutely need them. Perhaps add thread groups and support for cooperative threads a.k.a. fibers. IMO these are far more important than concepts, because everyone uses/will soon be using threads.
我想删除
=delete。已经有一个常见且被接受的习惯用法来达到相同的效果（将有问题的函数声明为私有）。 我认为此功能只会生成大量“我使用
=delete从派生类中删除基类函数，但仍然可以使用基类指针调用它”的问题。更不用说让人们对
delete关键字（现在）的两个含义感到困惑。I'd like to remove
=delete.There's already a common and accepted idiom for acheiving the same effect (declare the function in question as private). I think this feature will just generate lots of 'I used
=deleteto remove a base class function from my derived class, but it can still be called using a base class pointer' questions.Not to mention confusing people between the (now) two meanings of the
deletekeyword.去掉模板代码上的错误消息页面！
IIRC 概念应该解决 C++ 编码器的一个大问题：STL 的人类可读错误消息。 坏消息是这个问题没有得到解决。
Strip away the pages of error messages on template code!
IIRC concepts should solve a big C++ coder problem: Human readable error messages for the STL. Its bad news that this issue isn't addressed.
未命名的函数/lambda 函数让我紧张。 函数对象非常好并且是明确的，因此更容易阅读和查找。
另一方面，我有点喜欢概念，尽管我肯定不会每天都使用它们。
The un-named function / lambda function stuff makes me nervous. Function objects are perfectly good and are explicit, thus easier to read and find.
On the other hand I kinda liked concepts, though I certainly would not have used them every day.