2.看《Thinking In C++》，不要看《C++变成死相》；

3.看《The C++ Programming Language》和《Inside The C++ Object Model》,不要因为他们很难而我们自己是初学者所以就不看；

4.不要被VC、BCB、BC、MC、TC等词汇所迷惑——他们都是集成开发环境，而我们要学的是一门语言；

5.不要放过任何一个看上去很简单的小编程问题——他们往往并不那么简单，或者可以引伸出很多知识点；

6.会用Visual C++，并不说明你会C++；

7.学class并不难，template、STL、generic programming也不过如此——难的是长期坚持实践和不遗余力的博览群书；

8.如果不是天才的话，想学编程就不要想玩游戏——你以为你做到了，
其实你的C++水平并没有和你通关的能力一起变高——其实可以时刻记住：学C++是为了编游戏的；

9.看Visual C++的书，是学不了C++语言的；

10.浮躁的人容易说：XX语言不行了，应该学YY；——是你自己不行了吧！？

11.浮躁的人容易问：我到底该学什么；——别问，学就对了；

12.浮躁的人容易问：XX有钱途吗；——建议你去抢银行；

13.浮躁的人容易说：我要中文版！我英文不行！——不行？学呀！

14.浮躁的人容易问：XX和YY哪个好；——告诉你吧，都好——只要你学就行；

15.浮躁的人分两种：a)只观望而不学的人；b)只学而不坚持的人；

16.把时髦的技术挂在嘴边，还不如把过时的技术记在心里；

17.C++不仅仅是支持面向对象的程序设计语言；

18.学习编程最好的方法之一就是阅读源代码；

19.在任何时刻都不要认为自己手中的书已经足够了；

20.请阅读《The Standard C++ Bible》(中文版：标准C++宝典)，掌握C++标准；

21.看得懂的书，请仔细看；看不懂的书，请硬着头皮看；

22.别指望看第一遍书就能记住和掌握什么——请看第二遍、第三遍；

23.请看《Effective C++》和《More Effective C++》以及《Exceptional C++》；

24.不要停留在集成开发环境的摇篮上，要学会控制集成开发环境，还要学会用命令行方式处理程序；

25.和别人一起讨论有意义的C++知识点，而不是争吵XX行不行或者YY与ZZ哪个好；

26.请看《程序设计实践》，并严格的按照其要求去做；

27.不要因为C和C++中有一些语法和关键字看上去相同，就认为它们的意义和作用完全一样；

28.C++绝不是所谓的C的“扩充”——如果C++一开始就起名叫Z语言，你一定不会把C和Z语言联系得那么紧密；

29.请不要认为学过XX语言再改学C++会有什么问题——你只不过又在学一门全新的语言而已；

30.读完了《Inside The C++ Object Model》以后再来认定自己是不是已经学会了C++；

31.学习编程的秘诀是：编程，编程，再编程；

32.请留意下列书籍：《C++面向对象高效编程
（C++ Effective Object-Oriented Software Construction）》
《面向对象软件构造(Object-Oriented Software Construction)》
《设计模式（Design Patterns）》《The Art of Computer Programming》；

33.记住：面向对象技术不只是C++专有的；

34.请把书上的程序例子亲手输入到电脑上实践，即使配套光盘中有源代码；

35.把在书中看到的有意义的例子扩充；

36.请重视C++中的异常处理技术，并将其切实的运用到自己的程序中；

37.经常回顾自己以前写过的程序，并尝试重写，把自己学到的新知识运用进去；

38.不要漏掉书中任何一个练习题——请全部做完并记录下解题思路；

39.C++语言和C++的集成开发环境要同时学习和掌握；

40.既然决定了学C++,就请坚持学下去，因为学习程序设计语言的目的是掌握程序设计技术，而程序设计技术是跨语言的；

41.就让C++语言的各种平台和开发环境去激烈的竞争吧，我们要以学习C++语言本身为主；

42.当你写C++程序写到一半却发现自己用的方法很拙劣时，请不要马上停手；
请尽快将余下的部分粗略的完成以保证这个设计的完整性，然后分析自己的错误并重新设计和编写（参见43）；

43.别心急，设计C++的class确实不容易；自己程序中的class和自己的class设计水平是在不断的编程实践中完善和发展的；

44.决不要因为程序“很小”就不遵循某些你不熟练的规则——好习惯是培养出来的，而不是一次记住的；

45.每学到一个C++难点的时候，尝试着对别人讲解这个知识点并让他理解——你能讲清楚才说明你真的理解了；

46.记录下在和别人交流时发现的自己忽视或不理解的知识点；

47.请不断的对自己写的程序提出更高的要求,哪怕你的程序版本号会变成Version 100.XX；

48.保存好你写过的所有的程序——那是你最好的积累之一；

49.请不要做浮躁的人；

50.请热爱C++!

Pattern Mining and the Wrong Mindset
    人们很容易落入这样一个怪圈，认为算法比赛是一系列不同的可分类的剧情问题的集合。对于那些做过很多剧情问题的人来说，他可能知道这种类型的题目只有很少的一部分（尤其是上课时教授反复强调的部分）。当你读到一个特定形式的问题时，你的思维是，“哦，这个是X问题，然后就对号入座”。可能有很多次这种思维定势是可行的，但是当你做过一定数量的Topcoder SRM之后，大多数程序员会意识到一类的题目并且不断的进行练习，这种做题目的方法在很多比赛中都会成功。

    尽管如此，这个方法是有害的。你可能很多次阅读完题目描述之后，假定它是类型Q的题目并且开始进行编码，但最后发现你的代码一个样例都过不了。你会回头重读问题并发现这个问题和你经验中的不一样。这个时候，你对你的练习感到了麻痹，你不能指出适用于这个问题的类型。这种情况你会经常看到，当问题是从原有问题派生出的时候，很多富有经验的程序员都不能完成这个问题，因为他们被他们的经验蒙蔽了。

    思维定势导致了这样的思考。只有通过抛掉你以前的想法，并且重新学习必要的关键技巧才能使得你的rating稳步的上升。   

Coding Kata
    这里是你的第一个练习：在Practice Room中挑选任何一道你没有做过的问题。努力去搞定它，不管花多久（把比赛的解题报告看作最后一招）。让它通过系统测试，然后计算一下你花了多久完成它。接着，把你的解决方案清楚，然后试着再打一遍（剪切，粘贴显然达不到效果）。再次的让它通过系统测试。记下你第二次花了多久。接着，清除它然后再做一次，并且再次让它通过系统测试，然后记录下最终所用的时间。

    你第一次通过的所花的时间是你在对题目一无所知的情况下记录的。第二次通过的时间通常是第一次的时间减去你花费在理解题意上的时间。（不要感到惊讶，当你在第二次过程中重复犯一些错误）。最后一次的记录时间是你的潜能，如果你在读完题后能立刻思考出正确的做法，那么你可以在比赛中很快的解决它。让这些数字给你些启发；迅速的解决此类问题还是很有可能的，而不需要很快的打字速度。从第三次中你可以感受到你已经知道了策略，代码将会是什么样子，哪里你会犯错误等等。这就是有着正确解法时候的感觉，这种感觉就是未来比赛中的你的目标。

   在武术文化中，有种叫做空手道。武术家按照一系列的手法进行练习，通常用来抵挡对方的攻击（或者说有的时候是防卫），或者预测性的来防护。首先这种类型的练习没有任何意义，因为它看起来和打斗时没有章法的现实不符。更进一步的，它似乎在鼓励前面一张所提出的思维套路。只有在每个题目经过三次编码之后，你才能真正理解kata的好处。kata使得它的参与者能够在大脑中有一个计划，并且鼓励他们仔细思考问题。进攻就是最好的方法，它可以在编码，调试，提交的整个过程中使用。

Approach Tactics
    现在你知道方法是什么样了，也知道它们的具体内容了，你会意识到你学会了许多不同类型的方法。你能给出它们的名字吗？“哦，那题我用的是DP(动态规划 dynamic programming)”，“是吗，我本来可以用贪心做的”“不要告诉我暴力就能过了”。实际上，你给每个问题取的名字都不太恰当，因为你不能把每个问题归结为仅仅是贪心或者仅仅是暴力解法。问题的类型有无数多个，而解决方案的类型甚至更多，而且在每个解决方案中有用无穷多种类型的变化。这里的名字仅仅是完成解决方案的一个高度的概括。

    在一些较好的比赛报告中，都有一个解决问题的详尽描述。下次当你看比赛的总结时，并且遇到一个比较好的问题时，从中寻找方法的路数和构造方法。你会注意到在路数之间有一定的颗粒性，这就暗示了思考的一个方向。将观察到的策略和方法来规划你的方法，转换，引导并将其融入代码中，使得接近正解或者至少远离错解。当你准备方法的时候，思路就是想尽所有你会的策略方法来决定方法，所有你以前写过的代码都会在你的脑海中。这相当于你说服你自己那些将要写的代码能够工作。

    有一定数学背景的程序员会重新审视这个方法，因为许多方法策略和证明的技巧相似。玩象棋的人能够从当前一步中看到好多步。做应用开发的设计者可能在用到设计模式的时候就认识到这个方法了。在许多其它的问题中，都存在一个和它类似的类型。

    练习这种类型的思考方式并且在众多方法中选择你钟爱的，记录下你的问题的解决方案并且在SRM之后写下你自己的表现的一点分析是非常有益的。详细的描述你的解决方案每一步是怎样工作的，使得其他人能够理解并且写出方法如果他们看了你的解释之后。写下你的方法不仅可以帮助你理解你在编程时自己的思路，还能发现你在做的时候时一些易错之处。记住，学会你不懂的知识是很困难的。

Breaking Down a Problem
    让我们谈谈最常见的一个方法：问题分解。这在有的时候也叫做自顶向下编程：大意是你的代码必须按顺序执行一系列的步数，从简单的决策开始考虑。因此刚开始应当计划你的主函数需要什么，然后在看子函数要做些什么。这不仅可以让你很快的编写出原型（因为你仅仅编写你所需要的代码而没有其他任何东西），还能把问题划分成更小的部分，更多切实可行的部分。

    用到这个方法的一个很好的例子是 2002 TopCoder Invitational第二轮中的MatArith。这个问题需要你计算一个包含矩阵的表达式。你知道为了得到数字，你需要对它们进行解析（因为它们是字符串数组）并且将这些值传入计算器中，然后将他们转变为一个字符串数组，就完成了。因此你需要一个打印的函数，一个解析的函数和一个计算函数。不需要更加多的考虑，加入你已经写好了这三个函数，那么问题可以在一行之内被解决：

public String[] calculate(String[] A, String[] B, String[] C, String eval){
   return print(calc(parse(A),parse(B),parse(C),eval));
}

    这个简单方法的好处在于它将你的思维引导至函数的层次中。你现在可以把工作分为三步了：构建一个解析函数，一个打印函数和一个计算函数，将代码段切割成小段。如果你切割的足够好的话，你根部不用考虑最简单的步数，因为它们将会是原子的（这个下面将会谈到更多）

。事实上这个问题将会被很快的分割直到矩阵的乘法和加法函数，需要注意的仅
仅是读清题意并且调用恰当的函数。这种策略带来了一种编程方法名为函数式编程。网络上有许多关于这个的文章，甚至TopCoder中有一篇radeye写的文章，很深入的讲解了这个概念，但是概念的意思是，如果能够合理的分割，那么代码将在函数之间传递所有的参数信息，并且步数之间不需要存储任何数据，这就避免了很难调试的副作用的可能性（代码中不期望在步数间改变变量）。

    这个策略在递归问题上也表现的相当好。递归代码的背后的整个思想就是将问题分成更小的和原问题相似的子问题，由于你正在写的函数是原问题，因此你几乎完成了工作。

Plan to Debug
    无论何时你使用一个方法的时候，你都应该有一个调试代码的计划。这个是每一个方法薄弱的一个部分。总有一个使得解决方案失败的方法，通过事先考虑它会不能工作的多种情况，你可以在编码之前避免这些bug。更进一步的，如果你不能过样例，你知道应该在哪里找出问题。最后，通过查找代码的压力值，向自己证明所用方法是个好方法很会容易。

    在自顶向下的方法中，分解问题能够让你分离那些可能出现问题的部分，并且它能够让你组合测试那些看起来用的最多的子函数片段。并且还有一个好处，当你修复了一个bug，你把代码分解成了函数。这是因为bug在每个使用的地方都要修复。另外一个方法是程序员将代码段粘贴/复制到任何一个需要的地方，这将使得很难修复并且导致更多的bug。同样，当你在从顶向下的方法中找bug时，你应该首先查找函数内部的错误，而后再查找函数调用间的错误。这些部分组成了一个调试的策略：先看哪里，怎样测试你的思路是错误的，怎样验证代码片段并且继续。只有在足够的练习之下，你才能找到一个好的调试策略。

Atomic Code
    当你碰到一段你不能再分解的代码片段时，这就是原子代码。希望你知道怎样去编写这些部分，并且这些部分组成了最基本的原子代码的形式。但是，当你碰到一个问题不知如何下手的时候，不要泄气；这些难以解决的核心正是使得问题有趣的地方所在，有的时候是否能够提前看到将导致能否尽早的找到正确的方法并且放弃错误的方法而浪费大量时间的巨大差异。

    你写的最常见的原子代码的类型就是原语了。对于了解语言的库我一直很支持。这就是知识的用处。为你节省时间的最好的方法是在你的方法和你知道代码可能复杂的部分的情况下使用原子代码或者自带的库还是类呢？

    你写到第二种类型的原子代码我称它为语言技巧。这些通常是该语言中用来之下特定操作的，如找出数组中最小元素的索引，或者将一个用空格分隔的字符串分割成序列。这些技巧和准备一个方法一样至关重要，因为如果你知道了怎样做这些基础的操作的话，将会使得自顶向下的方法中更多的任务原子化，从而将正确的解法变得简短。除此之外，这使得这些代码中的原子操作出错的可能性减少。更进一步的，如果你要执行一个你所知道的语言技巧所能做的任务时，你可以很轻松的改变代码来进行适应（例如：根据启发式在一个数组中找到最大元素的索引将会变得很简单如果你知道怎样对类似的任务进行编码）。找出这些公共的语言技巧将成为你日常练习的元素之一，任何原子代码都应该随着你的思考从你的指尖流淌出来。

    另外一个方面，我必须强调使用代码库。我知道这是一个竞赛话题，许多成功的程序员在编码前使用一个库作为预先插入的代码段。这是合法的（尽管2004 TopCoder Open后的规则可能会改变以后的合法性），并且使用库有着很明显的优点，主要是声明了一些你的自顶向下方法的原语，并且有助于快速构建自底向上的方法（下面将会谈到）。这是我的观点。尽管如此，使用代码库的缺点要超过它的优点。库函数之间的执行有的时候会减慢你的编码，因为你需要使得你的输入满足你所要使用的代码的原型。库代码大多是不易改变的，因此，如果你的库要求做的事情并没有很明白的定义的话，你会发现你在代码技巧和本应该实现的算法之间进行摸索。并且也有可能你的库代码并不是没有bug的，并且在比赛中图调试你的库是非常可怕的，因为你需要把你已经交的代码进行修改，还要在你打开新的问题前去修改模板。此外，库在在线比赛中是不允许使用的。最后，使用库代码（或者宏）将使得你习惯于理解你的库而不是语言的本身，这将会使得你不能够在challenge阶段彻底的理解其他程序员的代码。如果用的得当，你的库很强大，但不是对任何东西都适合的终极武器。

    有可能会出现你无法将一个原子代码再进行分段。这时你应当对代码进行分析，并思考当前的方法。我是否应该将任务分割成另外一种形式呢？我应该将中间值进行另外一种形式的存储吗？或者也许这正是问题很难解决的关键点？在你找到关键点之前任何事情都要考虑到。甚至当你意识到你无法解决这些点时，用手算来看怎样可以更快的处理，这些方法构成了剩下的方法策略。