C++基于经验的错误特征
最近，一位同事询问我对 C++ 代码中异常规范的使用的看法，我翻出了 Herb Sutter 的这篇文章： 异常规范的实用视角。与赫伯·萨特的大多数文章一样，这篇文章是一本教育读物，但简短的答案是“不要这样做”。
在总结中，他提到了一首题为“实施前的夜晚”的诗，其中，标准委员会实际上屈服于用户的要求，在最后一刻添加了功能，却发现它做了什么要求，它并没有真正做到他们想要的。是的，异常规范符合这一要求。正如他所说，“这个功能在当时看来是个好主意，而且这正是一些人所要求的。”如果这还不够，他还会访问“出口”，结果也很悲惨。
所以问题是：如果你不想经历眼泪，C++ 的哪些“功能”被证明是被破坏的，并且不应该被使用。这可能会引起主观争论，但我希望人们能够引用具体的经历，即部署该功能只是为了引起可衡量的问题。更好的是引用像萨特（或深入参与标准的任何人）这样的知名人士的文章，警告人们不要使用某个功能。
Recently a colleague asked my opinion on the use of exception specifications in C++ code, and I was able to dredge up this article by Herb Sutter: A Pragmatic Look at Exception Specifications. The article, like most by Herb Sutter, is an educational read, but the short answer is "don't do that."
In the summary, he makes reference to a poem entitled "Twas the Night Before Implementation", wherein, effectively, a standards committee bows to the demands of users to add a feature at the last minute, only to discover that while it does what was asked for, it doesn't really do what they wanted. And yes, exception specifications fit that bill. As he says, "The feature seemed like a good idea at the time, and it is just what some asked for." If that is not enough, he then visits ''export'' with similar sad results.
So the question is this: What 'feature' of C++ turns out to be broken, and should not be used, if you do not wish to experience tears. This may be prey to subjective bickering, but I hope people will cite a specific experience where the feature was deployed only to cause measurable problems. Even better would be citations of articles by leading lights like Sutter (or anyone deeply involved in the Standard) warning people off of a feature.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您还包含库功能：
auto_ptr。它有其用途，但也很容易被滥用。下一个 C++ 标准也将弃用它们，转而使用更安全、更灵活的 std::unique_ptr。If you include library features as well:
auto_ptr. It has its uses but it's also easy to misuse. The next C++ standard will deprecate them as well in favor of the safer and more flexible std::unique_ptr.