C 里有多少技巧？C 里有多少诀窍？总之，C 有多少复杂之处？
公平地说，大多数窍门和技巧在最近几年都已被发现了（例如，modern C ），已用在了真实需求中，特别是实现高灵活性和属性类库组件的需求（考虑任何在boost中的组件）。他们确实（在一些程度上说）引导了一些现实问题的完美解决方案。能够这样考虑这件事情：假如您处在这样一种情况下，您得使用窍门来实现一些确实有用的事情；或您不使用窍门实现他，那么其他人就不会从使用他上得到好处。您会选择哪种？我想聪明的人会选择前一种，不管窍门有多难，实现有多麻烦。
但是任何的争论都不能改变这样的事实：那就是我们值得拥有一种能够在代码中干净地表达我们的想法的语言。以boost.function/boost.bind/boost.tuple为例，variadic templates（可变模板）能够很容易地（通过减少通信线路为原来的十分之一）实现这三个（将来会更多）类库，代码会变得简洁，尽可能地简单。Auto, initializer-list, rvalue-reference, template-aliasing, strong-typed enums, delegating-constructors, constexpr, alignments, inheriting-constructors,等；任何这些C 0X的特性，他们都有一个一起的目标——去除语言中的各种附属复杂性或阻碍。
就像Bjarne Stroustrup说的，显然，C 太复杂；显然，人们有些恐惧他而放弃他。但是“人们也需要相对复杂的语言来处理绝对复杂的问题”。我们不可能减少语言的特性来使语言变得更有力。像是模板这样复杂的特性，或是更复杂的多重继承，这些可能会对您的需求更有用，您只需要很认真、必要地了解他们，这样就不会搬起石头砸到自己的脚。在C 的任何复杂性中，唯一妨碍我们的就是附属复杂性（有人称他为“阻碍”），他不是语言所支持的范例（只支持三个）。这就是我们为什么要加强C 0X的重要原因，因为他的目标是去除C 中长期存在的附属复杂性，使任何的诀窍变得融合（这种东西数量绝对很大；您能够参看有关C 的书籍或是C 根库，您就会明白我在说什么了），这样我们才能清楚、直接地表达我们的想法。
结论
C 很难，难于正确使用。所以当您决定要用他的时候，一定要小心谨慎，一定要清楚您处在什么位置，您真正想要什么。下面是个简单的导引：我们需要高效吗？假如需要，那么在我们的代码中需要抽象吗（这个问题一定要慎重考虑，因为很难估计使用C 的高水平特性所带来的好处是否超过了正确使用他们的风险；正确的答案取决于您的编程水平训练的有多好，您遵循什么编码标准，连同这种标准加强的有多好，等）？
假如需要，那么就使用C ，否则，我们需要C 类库来减少我们的工作量吗？假如需要，那么就使用C ，但同时要谨记您在做什么——假如您的代码并不真的需要任何梦幻抽象，那就不要勉强使用他们；不要仅仅因为您写的代码是.cpp，您使用了C 编译器，就使用类或是模板。
否则，就使用C ，但是您可能会怀疑为什么不用C 的C编码核心。同样的理由：人们很容易被稀奇古怪的语言特性所迷惑，即使他们真的不知道这些特性对他们是否有帮助——我能够不厌其烦地告诉您，我写过一串类，只是为了找出“这些类到底是什么鬼东西”。所以，假如您能坚持C核心或是带有部分C 的C核心，并且保持事情简单（KISS）；或假如您的代码需要从C移植到C ，那么就使用C 吧！但是一定要小心。另一方面，假如您的代码既无需高性能特性，也无需C 类库，因为您要做的事情很简单，以至于您甚至无需像是containers或是strings这样方便的组件；或您认为您的项目中使用C 能给您带来的好处不足以值得您冒险；或只是因为您没有足够能正确使用C 的人员，那么您应该还是坚持用C。
最主要的：保持事情简单（KISS）（但是要记住这种简单能够通过使用高水平类库来达到）；必要的时候（即使是必要，也要少用；遵循好的设计原理，养成好的习惯）使用抽象。
[1] [2] [3]
