有了新标准，就有了新的做事方式，很多都比旧方式更好，但旧方式还是可以的。同样清楚的是，出于向后兼容性的原因，新标准并没有正式弃用。所以剩下的问题是：
哪些旧的编码方式肯定不如 C++11 风格，我们现在能做些什么呢？
在回答这个问题时，您可以跳过“使用自动变量”之类的明显内容。
【问题讨论】：
auto_ptr 也已被弃用。
final 说明符来防止类派生std::auto_ptr 工作的神奇方式。shrink_to_fit() 成员函数，这应该消除了与临时交换的需要。= delete 语法是一种更直接的方式来表示特定功能被明确拒绝。这适用于防止堆分配（即，=delete 用于成员 operator new）、防止复制、分配等。result_of：使用类模板result_of 应替换为decltype。我认为result_of 在可用时使用decltype。NULL 应重新定义为 nullptr，但请参阅 STL's talk 了解他们决定反对它的原因。我想我会停在那里！
【讨论】：
result_of。尽管之前需要麻烦的typename，但我认为typename result_of<F(Args...)::type 有时比decltype(std::declval<F>()(std::declval<Args>()...) 更容易阅读，并且在工作文件中接受N3436 后，他们都为SFINAE 工作（这曾经是一个优势decltype 中的 result_of 没有提供）
曾有人争论说应该按const 值返回，而不仅仅是按值返回：
const A foo();
^^^^^
这在 C++98/03 中基本上是无害的，甚至可能发现了一些看起来像这样的错误：
foo() = a;
但是通过 const 返回在 C++11 中是禁忌的，因为它禁止移动语义：
A a = foo(); // foo will copy into a instead of move into it
所以放松一下并编写代码：
A foo(); // return by non-const value
【讨论】：
A& operator=(A o)& 而不是A& operator=(A o)。这些可以防止愚蠢的错误并使类的行为更像基本类型，并且不会阻止移动语义。
一旦您可以放弃0 和NULL 转而支持nullptr，就这样做！
在非泛型代码中，使用0 或NULL 并不是什么大问题。但是，一旦您开始在通用代码中传递空指针常量，情况就会迅速改变。当您将0 传递给template<class T> func(T) 时，T 会被推断为int 而不是空指针常量。之后它不能转换回空指针常量。如果宇宙只使用nullptr，这将导致一系列问题根本不存在。
C++11 不会将 0 和 NULL 弃用为空指针常量。但是你应该像它那样编码。
【讨论】：
std::nullptr_t。
0 或NULL 用于空指针”）。
Safe bool idiom → explicit operator bool()。
私有复制构造函数（boost::noncopyable）→X(const X&) = delete
Simulating final class with private destructor and virtual inheritance → class X final
【讨论】：
让您避免在 C++11 中编写基本算法的原因之一是 lambdas 与标准库提供的算法相结合的可用性。
我现在正在使用这些，令人难以置信的是，您经常使用 count_if()、for_each() 或其他算法来告诉您想要做什么，而不必再次编写该死的循环。
一旦您使用带有完整 C++11 标准库的 C++11 编译器，您就再也没有理由不使用标准算法来构建您的编译器了。拉姆达干脆杀了它。
为什么？
在实践中（在我自己使用过这种编写算法的方式之后），阅读由直截了当的单词构建的东西，意思是做了什么，比阅读一些你必须解密才能知道含义的循环要容易得多。也就是说，自动推导 lambda 参数将有助于使语法更容易与原始循环进行比较。
基本上，阅读使用标准算法制作的算法要容易得多，因为文字隐藏了循环的实现细节。
我猜现在我们必须考虑更高级别的算法，因为我们有更低级别的算法可以构建。
【讨论】：
for_each 比等效的基于范围的 for 循环更好，其中 lambda 的内容在循环中。代码看起来或多或少相同，但 lambda 引入了一些额外的标点符号。您可以使用类似 boost::irange 的等价物将其应用于更多循环，而不仅仅是那些明显使用迭代器的循环。此外，基于范围的 for 循环具有更大的灵活性，如果需要，您可以提前退出（return 或break），而使用for_each，您需要抛出。
for 的可用性使通常的it = c.begin(), const end = c.end(); it != end; ++it 成语失效。
for_each 算法相对于基于范围的 for 循环的优势之一是您不能 break 或return。也就是说，当您看到for_each 时，您无需看身体就知道没有这种狡猾。
std::for_each(v.begin(), v.end(), [](int &i) { ++i; }); 与for (auto &i : v) { ++i; } 进行比较。我接受灵活性是双刃的（goto 非常灵活，这就是问题所在）。我不认为在for_each 版本中不能使用break 的限制弥补了它所要求的额外冗长——for_each 的用户这里是 IMO 牺牲实际可读性和便利性来换取一种理论for_each原则上更清晰，概念上更简单。在实践中，它并没有更清晰或更简单。
您需要减少实现swap 的自定义版本的频率。在 C++03 中，通常需要一个有效的非抛出 swap 以避免代价高昂和抛出副本，并且由于 std::swap 使用两个副本，因此 swap 通常必须自定义。在 C++ 中，std::swap 使用 move，因此重点转移到实现高效且不抛出的移动构造函数和移动赋值运算符上。因为对于这些，默认值通常就可以了，这将比在 C++03 中少得多。
通常很难预测会使用哪些成语，因为它们是通过经验创造出来的。我们可以期待“有效的 C++11”可能在明年发布，而“C++11 编码标准”仅需要三年时间，因为还没有必要的经验。
【讨论】：
我不知道它的名字，但 C++03 代码经常使用以下构造来代替缺少的移动赋值：
std::map<Big, Bigger> createBigMap(); // returns by value
void example ()
{
std::map<Big, Bigger> map;
// ... some code using map
createBigMap().swap(map); // cheap swap
}
这避免了由于复制省略与上面的swap 结合而导致的任何复制。
【讨论】：
map 中构造返回值。如果map 已经存在，而不仅仅是正在构建，那么您展示的技术很有用。如果没有“便宜的默认构造函数”注释并且在该构造和交换之间使用“// ...”，该示例会更好
当我注意到使用 C++11 标准的编译器不再出现以下代码错误时：
std::vector<std::vector<int>> a;
对于所谓的包含运算符>>，我开始跳舞。在早期版本中，人们必须这样做
std::vector<std::vector<int> > a;
更糟糕的是，如果您不得不对此进行调试，您就会知道由此产生的错误消息是多么可怕。
但是，我不知道这对你来说是否“显而易见”。
【讨论】：
按值返回不再是问题。使用移动语义和/或返回值优化（依赖于编译器）编码功能更自然，没有开销或成本（大部分时间）。
【讨论】：