Answers:
如果您想争论语言的语义和标准语，那么标准就非常重要。（我并不是说这完全贬义。）如果您只是想用该语言完成工作（相对于该语言），那么情况就不那么如此了。
一旦对标准库感到满意，该标准就可以很好地引用标准库（对于语言本身而言不是很多），但是我很犹豫地建议以这种方式使用它。大多数人似乎在其他材料上做得更好。就是说，当我需要查找有关stdlib的内容时，我经常会使用标准。
但是，阅读委员会的草稿和论文是与C ++ 0x并驾齐驱的一种方法-实际上，目前只有少数几种方法之一。
对于SO和其他论坛，我会犹豫地引用该标准，除非发布者似乎明确并肯定会受益–也许他们已经要求这样做，或者我认为他们对此隐含期望。在大多数情况下，尤其是对于刚接触C ++的程序员来说，引用它似乎并没有多大帮助。
在一个大型团队中，通常应该有一个（但通常不会再有）至少至少相当了解该标准的人，以便他们可以执行诸如解决有关特定代码是否符合标准要求之类的任何论据/问题之类的事情。
但实际上，这些答案需要通过判断和经验来调整。（当前）标准说export是一个关键字，并说明其作用。实际上，对于大多数编译器而言，它根本无法实现这一目标。同样，在很多情况下，如果您有三个人不同意某个特定的代码以及标准可能对它说些什么，那么这可能表明该代码可能需要重写才能更加简单明了。
同时，大多数团队将在一个平台上完成大部分工作，并有一个标准（以及至少相当熟悉该标准的人）来检查您正在做的事情与该平台的联系不是太紧密有用。
作为一名C ++开发人员，我一整年都在挣钱，而没有阅读该标准。实际上，在头两年左右的时间里，除了Stan Lippman撰写的C ++ Primer和MSDN文章之外，我什至没有读过其他文章。因此有可能-实际上，我担心大多数产生C ++代码的人甚至都没有读过像Effective C ++等这样的基础著作。我本人后来才发现的。
恕我直言，要成为一名优秀的C ++开发人员，必须了解语言的内在逻辑（正如Scott Meyers指出的那样，C ++是大约4种不同的语言）以及常见的成语和陷阱，并准备随时学习更多。读SO上的线程可以教很多有关极端情况的知识，如果有人想真正深入研究，那么反过来值得阅读标准的相关部分。但是对我们大多数人来说，阅读全部内容可能很少。