亚洲欧美日韩久久精品第一区,欧美伊人久久大香线蕉综合69,国产精品久久新婚兰兰

初学者，你应当如何学习C++以及�~�程

snowball — Sun, 06 Apr 2008 04:07:00 GMT

JavaScript是世界上最受误解的语言�Q�其实C++何尝不是。坊间流传的错误的C++学习�Ҏ��一抓就是一大把。我自己在学习C++的过�E�中也走了许多弯路，��费了不��时间�?/p>

　　��Z��么会存在�q�么多错误认�?原因主要有三个，一是C++语言的细节太多。二是一些著名的C++书籍��d��(不管有意�q�是无意)暗示语言�l�节的重要性和有趣。三是现代C++库的开发哲学必��ȝ��C��些犄角旮旯的语言�l�节(但注意，是库设计�Q�不是日常编�E?。这些共同塑造了C++�C��的整体心态和哲学�?/p>

　　单是�W�一条还未必能够成气候，其它语言的细节也不少(��管比�vC++��h��q�是��巫见大�?�Q�就拿javascript来说�Q�作用域规则�Q�名字查找，closure�Q�for/in�Q�这些都是细节，而且其中�q�有�q�反直觉的。但许多动态语�a�的程序员的理忉|��猜大�U�是学到哪用到哪�|�。但C++��׃��一样了�Q�学C++之�h有一�U�类��g��被暗�C�的潜在心态，��是一定要先把语言核心基本上吃透了才能下手写出漂亮的程序。这首先��错了。这个意识�Ş成的原因在第二点�Q�C++书籍。市面上的C++书籍不计其数�Q�但有一个共同的�~�点�Q�就是讲语言�l�节的书太多——《C++ gotchas》，《Effective C++》，《More Effective C++》，但无可厚非的是，C++是这样一门语�a��Q�要拿它满��C��~�程理念的需求，��其是C++库开发的需求，�q�必��d��x��语言�l�节�Q�乃至于在C++中利用语�a��l�节已经成了一门学问。比如C++模板在设计之初根本没有想到模板元�~�程�q�回事，更没惛_��C++模板�pȝ��是图灵完备的�Q�这也就��D��了《Modern C++ Design》和《C++ Template Metaprogramming》的惊世骇俗�?/p>

　　�q�些技术的出现��Z��么惊世骇俗，打个比方�Q�就好比是一块大安��认�ؓ已经熟悉无比�Q�再无秘密可�a�的土��C��Q�突然某天有人挖到原来地下还蕴藏着最丰富的石沏V��在�q�之前的C++虽然也有一些细节，但也�q�算�Ҏ��掌握�Q�那可是C++�E�序员们的happy old times�Q�因为C++的一切都一览无余，everything is figured out。然而《Modern C++ Design》的��Z��告诉��Z��Q�“瞧�Q�还有多��细节你们没有掌握啊。”于是C++�E�序员们久违的激情被重燃��h��Q�奋不顾�w�的�t�入�l�节的沼泽中。尤其是�Q�模板编�E�将C++的细节进一步挖掘到了极致——我们干嘛关心涉及类对象的隐式�{换的优先�U�高�?看看boost::is_base_of��可以知道有多诡异了�?/p>

　　但最大的问题�q�在于，对于�q�些�l�节的关注还真有它合适的理由�Q�我们要开发现代模板库�Q�要开发active library�Q�就必须动用模板�~�程技术，要动用模板编�E�技术，��必��d��用语�a�的犄角旮旯，enable_if�Q�type_traits�Q�甚臌��早就古井无�L的C宏也在�ؕ世中重生�Q�看看boost::preprocessor有多诡异��q��道了�Q�连C宏的囄��完备�?预编译期�?都被挖掘出来了。�ؓ什么要做这�?好玩?标榜?都不是，开发库的实际需求。但�q�也正是最大的悲哀了。在boost里面因实际需求而动用语�a��l�节最�l�居然能��奇的完成�Q务的最好教材就是boost::foreach�Q�这个小设施对语�a��l�节的发掘达��C��惊天地泣鬼神的地步，不信你先试着自己�ȝ��看它的源代码�Q�再看看作者介�l�它的文章吧。而boost::typeof也不甘其后——C++语言里面有太多被“发现”而不是被“发明”的技术。难道最初无意设�|�这些语�a�规则的家伙们都是Oracles?

　　因�ؓ没有variadic templates�Q��h们用宏加上缺省模板参数来实现�c�M��效果。因为没有concepts�Q��h们用模板加上析构函数的细节来完成�c�M��工作。因为没有typeof�Q��h们用模板元编�E�和宏加上无��的�l�节来实现目标�?C++开发者们的DIY�_��不可谓不强�?/p>

　　然而，如果仅仅是因��开发优�U�的库�Q�那么涉及这些细节都�q�是情有可原的，臛_��在C++09出现�q�且�~�译器厂商跟上之前，�q�些都还能说是不得已而�ؓ之。但我们�q�大的C++�E�序员呢?大众是容易被误导的，我也曄��是。以为掌握了更多的语�a��l�节��更牛，但实际却是那些语�a��l�节十有八九是��^时编�E�用都用不到的。C++中众多的�l�节虽然在库设计者手里面有其用武之地�Q�但普通程序员则根本无需�q�多��x��Q�尤其是没有实际动机的关注。一般性的�~�码实践准则�Q�以及基本的�~�程能力和基本功�Q�乃臛_��本的�E�序设计理论以及��法设计。才是真正需要花旉��掌握的东�ѝ�?/p>

　　学习最佳编码实跉|��学习C++更重要。看优秀的代码也比埋头用差劲的编码方式写垃圾代码要有效。直接、清晰、明了、KISS地表达意图比玩编码花招要重要�?/p>

　　避免去过问�Q何语�a��l�节�Q�除非必要。这个必要是指在实际�~�程当中遇到问题�Q�这样就��需要过问细节，也是最省事的，懒惰者原则嘛。一个掌握了基本的编�E�理念�ƈ有较强学习能力的�E�序员在用一门陌生的语言�~�程时就��拿着那本语言的圣�l�从索引��v也可以编出合格的�E�序来。十�q�学会编�E�不是指�Ҏ��门语�a�都得十年�Q�那一辈子才能学几门语�a�哪，如果按字母顺序学的话一辈子都别指望学到Ruby�?十年学习�~�程更不是指先把语言�Ҏ��从�_�到�l�全都吃透才敢下手编�E�，在实践中提高才是最重要的�?/p>

　　至于�q�种抠语�a��l�节的哲学�ؓ何能在社��里面呈野火燎原之势�Q�就是一个心理学的问题了。想像�h们在论坛上讨论问题时�Q�一个对语言把握很细致的��定能够得到更多的佩服�Q�而由于论坛上的问题大多是��问题，所以解军_��际问题的真正能力�q�不能得到显玎ͼ�也就是说�Q�知识型的�h能够得到更多佩服�Q�后者便成�ؓ动力和仿效的砝码。然而真正的�~�程能力是与语言�l�节没关�pȝ��Q�熟�l�运用一门语�a�能够帮你最佌��达你的意图，但熟�l�运用一门语�a��l�不意味着要把它的边边角角全都��C��。懂得一些常识，有了�~�程的基本直觉，遇到一些细节错误的时候再��L��书，是最节省旉��的办法�?/p>

　　C++的书�Q�Bjarne的圣�l�《The C++ Programming Language》是高屋建瓴的。《大规模C++�E�序设计》是挺务实的。《Accelerated C++》是最佛_��门的。《C++ Templates》是仅作参考的。《C++ Template Metaprogramming》是�_�֊��q�剩者可以玩一玩的�Q�普通程序员��都别碰的。《ISO.IEC C++ Standard 14882》不是拿来读的。Bjarne最�q�在做C++的教�Ԍ��C��是绝对可以期待的�?/p>

　　P.S. 关于如何学习�~�程�Q�g9的blog上有许多�_�ֽ�的文章：�q�里�Q�这里，�q�里�Q�这里�?实际上，我徏议你��L��g9老大的blog��M��底朝�?:P

　　再P.S. 书单?我是遑于�l�出一个类伹{��C++初学者必诅R��这�U�书单的。C++的书不计其数�Q�被公认的好书也不胜枚�D。只不过有些书容易给初学者造成一�U�错觉，��是“学习C++��应该是�q�个样子的”。比如有朋友提到的《高质量C/C++�~�程》，�q�本书有价��|��但不适合初学者，初学者读�q�样的书�Ҏ��一叉��目不见泰山。实际上�Q�正��的态度是，�l�节是必要的。但�l�节是次要的。其实学习编�E�我觉得应该最先学习如何用伪码表达思想呢，君不见《Introduction to Algorithm》里面的代码?《TAOCP》中的代�?哦，对了它们是自己徏立的语言�Q�但�q�种仅教学目的的语言的目的就是�ؓ了避免让写程序的��Z��开始就忘了写程序是��Z��完成功能�Q�以为写�E�序��是和语�a��l�节作斗争了。Bjarne说程序的正确性最重要�Q�boost的编码标准里面也��正��性列在性能前面�?/p>

　　此外�Q�一旦徏立了正确的学习编�E�的理念�Q�其实什么书(只要不是太垃圄��)都有些用处。都当成参考书�Q�用的时候从目录或烦引翻�Q�基本就对了�?/p>

　　再再P.S. myan老大和g9老大都给��Z��许多�_�ֽ�的见解。我不得不再加上一个P.S。具体我��׃��摘录了，如果你读到这里，请务必往下看他们的评论。�{载者别忘了转蝲他们的评�?-)

　　许多朋友都问我同一个问题，到底要不要学习C++。其实这个问题问得很没有意义。“学C++”和“不学C++”这个二分法是没意义的，��Z��?因�ؓ�q�个问题很表面，甚至很��Q�w�。重要的不是你掌握的语言�Q�而是你掌握的能力�Q�借用myan老大的话�Q�“重要的是这个磨�l�过�E�，而不是结果，要的是你�_�壮的腿�Q�而不是你�w�上背的那袋盐巴。”。此外学习C++的意义其实真的是醉翁之意不在酒，像C/C++�q�种�pȝ��U�语�a��Q�在学习的过�E�中必须要涉及到一些底层知识，如内存管理、编译连接系�l�、汇�~�语�a�、硬件体�pȝ��构等�{�等�{�知�?注意�Q�这不包括过分犄角旮旯的语言枝节)。这些东西也��是所谓的内功�?其实最最重要的内功还是长期学习所��练出来的自学能�?。对此大嘴Joel在《Joel On Software》里面提到的漏洞抽象定律阐述得就非常漂亮�?/p>

　　所以，�{�案是，让你成�ؓ高手的�ƈ不是你掌握什么语�a��Q�精通C++未必��p��让你成�ؓ高手�Q�不�_�N��C++也未必就能让你成��Z��手。我惛_��安��不会怀疑g9老大如果要抄起C++做一个项目的话会比大多数自认熟练C++的�h要做得漂亮。所以关键的不是语言�q�个表层的东西，而是底下的本质矛盾。当�Ӟ��不是说那��׃��么语�a�都不要学了，按照一�U�曹操的逻辑�Q�“天下语�a��Q�唯imperative与declarative耳”。C++是前者里面最复杂的一�U�，支持最�q�泛的编�E�范式。借用当初数学�p�d��学大会上一个老师的话�Q�“你数学都学了，�q�有什么不能学的呢?”。学语言是一个途径�Q�如果你把它用来��练自己�Q�可以。如果你把它用来作�ؓ学习�pȝ��底层知识的钥匙，可以。如果你把它用来作�ؓ学习如何�~�写优秀的代码，如何�l�织大型的程序，如何�q�行抽象设计�Q�可以。如果掉书袋�Q�光啃细节，我认��Z��可以(除非你必��要用到�l�节�Q�像boost库的coder�?�?/p>

然后再借用一下g9老大的《银弹和我们的职业》中的话�Q?/p>

　　银弹和我们的职业发展有什么相�q?很简单：我们得把旉��用于学习解决本质困难。新技术给高手带来方便。菜鸟们却不用指望被新技术拯救。沿用以前的比喻�Q?一��的摄媄师不会因为相机的更新换代而丢掉饭��，反而可能借助先进技术留下传世佳作。因为摄��q��本质困难�Q�还是摄影师的艺术感觉。热门技术也��q��于相机�?不停�q�新�Q�学习这个框�Ӟ��那个软�g�Q�好比成天钻研不同相机的说明书。而热门技术后的来龙去脉，才好比摄影技术。�ؓ什么推��个框�?它解决了什么其它框�?不能解决的问�?它在哪里适用?它在哪里不适用?它用了什么新的设�?它改�q�了哪些旧的设计?Why is forever. �?朋友聊天时提到Steve McConnell的《Professional Software Development》里面引了一个调查，说��Y件开发技术的半衰�?0�q�。也��是�?0�q�后我们现在知识里一半的东西�q�时。相当不坏。朋友打��道�Q�“应该说20�q�后IT界一半的技术过�Ӟ��我们学的�q�时技术远�q�超�q�这个比例。具体到某�h�Q�很可能5�q�他��废了”。话虽悲观，但可见选择学习内容的重要性。学�?本质技�?技术迟早过�Ӟ��技艺却常用长新)�q�有一好处�Q�就是不用看着自己心爱的技术受到挑战的时候干嚎。C/C++�q�时��p��时了呗，只要有其它的�pȝ��~�程语言。Java倒了��倒了呗，未必我不能用.net?Ruby昙花一现又如何。如果用得不爽，换到其它动态语�a��是了。J2EE被废了又怎样?未必我们��?做不出分布系�l�了?�q�里�q��D了更多的例子�?/p>

　　一句话�Q�只有�h是真正的银弹。职业发展的目标�Q�就是把自己变成银弹。那时候，你就不再是�h�Q�而是人弹�?/p>

　　最后就以我在Bjarne的众多访谈当中摘录的一些关于如何学习C++(以及�~�程)的看法结束吧(没空逐段��译了，只将其中我觉得最重要的几�D�译了一下，当然�Q�其它也很重要，�q�些�D�落是在Bjarne的所有采访稿中摘抄出来的�Q�所以强烈徏议都�q�目一�?�Q?/p>

　　I suspect that people think too little about what they want to build, too little about what would make it correct, and too much about "efficiency" and following fashions of programming style. The key questions are always: "what do I want to do?" and "how do I know that I have done if?". Strategies for testing enters into my concerns from well before I write the firat line of code, and that despite my view that you have to write code very early - rather than wait until a design is complete.

　　译：我感觉�h们过多关注了所谓“效率”以及跟随编�E�风格的潮流�Q�却严重忽视了本不该被忽视的问题�Q�如“我�I�竟惌��构徏什么样的系�l�”、“怎样才能使它正确”。最关键的问题永�q�是�Q�“我�I�竟惌��做什�?”和“如何才能知道我的系�l�是否已�l�完成了�?”就拿我来说吧，我会在编写第一行代码之前就考虑��试�Ҏ��Q�而且�q�还是在我关于应当早于设计完成之前就�q�行�~�码的观点的前提之下�?/p>

　　Obviously, C++ is very complex. Obviously, people get lost. However, most peple get lost when they get diverted into becoming language lawyers rather than getting lost when they have a clear idea of what they want to express and simply look at C++ language features to see how to express it. Once you know data absreaction, class hierarchies (object-oriented programming), and parameterization with types (generic programming) in a fairly general way, the C++ language features fall in place.

　　译：诚然�Q�C++非常复杂。诚�Ӟ��Z��q�失其中了。然而问题是�Q�大多数��Z��是因为首先对自己惌��表达什么有了清晰的认识只不�q�在去C++语言中搜��d��适的语言�Ҏ��时�q�失的，相反�Q�大多数人是在不觉成��a�律师的�\上迷失在�l�节的丛林中的。事实是�Q�只需�Ҏ��据抽象、类体系�l�构(OOP)以及参数化类�?GP)有一个相当一般层面的了解�Q�C++�U�L��的语�a��Ҏ��也��清晰�v来了�?/p>

　　Well, I don't think I made such a trade-off. I want elegant and efficient code. Sometimes I get it. These dichotomies (between efficiency versus correctness, efficiency versus programmer time, efficiency versus high-level, et cetera.) are bogus.

　　I think the real problem is that "we" (that is, we software developers) are in a permanent state of emergency, grASPing at straws to get our work done. We perform many minor miracles through trial and error, excessive use of brute force, and lots and lots of testing, but--so often--it's not enough.

　　Software developers have become adept at the difficult art of building reasonably reliable systems out of unreliable parts. The snag is that often we do not know exactly how we did it: a system just "sort of evolved" into something minimally acceptable. Personally, I prefer to know when a system will work, and why it will.

　　There are more useful systems developed in languages deemed awful than in languages praised for being beautiful--many more. The purpose of a programming language is to help build good systems, where "good" can be defined in many ways. My brief definition is, correct, maintainable, and adequately fast. Aesthetics matter, but first and foremost a language must be useful; it must allow real-world programmers to express real-world ideas succinctly and affordably.

　　I'm sure that for every programmer that dislikes C++, there is one who likes it. However, a friend of mine went to a conference where the keynote speaker asked the audience to indicate by show of hands, one, how many people disliked C++, and two, how many people had written a C++ program. There were twice as many people in the first group than the second. Expressing dislike of something you don't know is usually known as prejudice. Also, complainers are always louder and more certain than proponents--reasonable people acknowledge flaws. I think I know more about the problems with C++ than just about anyone, but I also know how to avoid them and how to use C++'s strengths.

　　In any case, I don't think it is true that the programming languages are so difficult to learn. For example, every first-year university biology textbook contains more details and deeper theory than even an expert-level programming-language book. Most applications involve standards, operating systems, libraries, and tools that far exceed modern programming languages in complexity. What is difficult is the appreciation of the underlying techniques and their application to real-world problems. Obviously, most current languages have many parts that are unnecessarily complex, but the degree of those complexities compared to some ideal minimum is often exaggerated.

　　We need relatively complex language to deal with absolutely complex problems. I note that English is arguably the largest and most complex language in the world (measured in number of words and idioms), but also one of the most successful.

　　C++ provides a nice, extended case study in the evolutionary approach. C compatibility has been far harder to maintain than I or anyone else expected. Part of the reason is that C has kept evolving, partially guided by people who insist that C++ compatibility is neither necessary nor good for C. Another reason-- probably even more important--is that organizations prefer interfaces that are in the C/C++ subset so that they can support both languages with a single effort. This leads to a constant pressure on users not to use the most powerful C++ features and to myths about why they should be used "carefully," "infrequently," or "by experts only." That, combined with backwards-looking teaching of C++, has led to many failures to reap the potential benefits of C++ as a high-level language with powerful abstraction mechanisms.

　　The question is how deeply integrated into the application those system dependencies are. I prefer the application to be designed conceptually in isolation from the underlying system, with an explicitly defined interface to "the outer world," and then integrated through a thin layer of interface code.

　　Had I had a chance to name the style of programming I like best, it would have been "class-oriented programming", but then I'm not particularly good at finding snappy names. The school of thought that I belong to - rooted in Simula and related design philosophies - emphasizes the role of compile-time checking and flexible (static) type systems. Reasoning about the behavior of a program has to be rooted in the (static) structure of the source code. The focus should be on guarantees, invariant, etc. which are closely tied to that static structure. This is the only way I know to effectively deal with correctness. Testing is essential but cannot be systematic and complete without a good internal program structure - simple-minded blackbox testing of any significant system is infeasible because of the exponential explosion of states.

　　So, I recommend people to think in terms of class invariants, exception handling guarantees, highly structured resource management, etc. I should add that I intensely dislike debugging (as ah hoc and unsystematic) and strongly prefer reasoning about source code and systematic testing.

　　Pros: flexibility, generality, performance, portability, good tool support, available on more platforms than any competitor except C, Access to hardware and system resources, good availability of programmers and designers. Cons: complexity, sub-optimal use caused by poor teaching and myths.

snowball 2008-04-06 12:07 发表评论

C++中的内存划分

snowball — Sun, 06 Apr 2008 04:02:00 GMT

在C++中，内存分成5个区�Q�他们分别是堆、栈、自由存储区、全局/静态存储区和常量存储区�?/p>

　　栈，��是那些��q��译器在需要的时候分配，在不需要的时候自动清楚的变量的存储区。里面的变量通常是局部变量、函数参数等�?/p>

　　堆，��是那些由new分配的内存块�Q�他们的释放�~�译器不�ȝ��Q�由我们的应用程序去控制�Q�一般一个new��p��对应一个delete。如果程序员没有释放掉，那么在程序结束后�Q�操作系�l�会自动回收�?/p>

　　自由存储区，��是那些由malloc�{�分配的内存块，他和堆是十分�怼�的，不过它是用free来结束自��q��生命的�?/p>

　　全局/静态存储区�Q�全局变量和静态变量被分配到同一块内存中�Q�在以前的C语言中，全局变量又分为初始化的和未初始化的，在C++里面没有�q�个区分了，他们共同占用同一块内存区�?/p>

　　帔R��存储区，�q�是一块比较特�D�的存储区，他们里面存放的是帔R��Q�不允许修改(当然�Q�你要通过非正当手�D�也可以修改�Q�而且�Ҏ��很多)

snowball 2008-04-06 12:02 发表评论

Memset ,memcpy,strcpy 区别

snowball — Sun, 06 Apr 2008 02:31:00 GMT

Memset 用来对一�D�内存空间全部设�|��ؓ某个字符�Q�一般用在对定义的字�W�串�q�行初始化�ؓ �?�?/span> �?/span> ‘\0�?/st1:chmetcnv> �Q?/span>

�?/span> :char a[100];memset(a, '\0', sizeof(a));

memset 可以方便的清�I�Z��个结构类型的变量或数�l��?/span>

如：

struct sample_struct
{
char csName[16];
int iSeq;
int iType;
};

对于变量
struct sample_strcut stTest;

一般情况下�Q�清�I?/span> stTest 的方法：

stTest.csName[0]='\0';
stTest.iSeq=0;
stTest.iType=0;

�?/span> memset ��非常方便：
memset(&stTest,0,sizeof(struct sample_struct));

如果是数�l�：

struct sample_struct TEST[10];
�?/span>
memset(TEST,0,sizeof(struct sample_struct)*10);

memcpy 用来做内存拷贝，你可以拿它拷贝�Q何数据类型的对象�Q�可以指定拷贝的数据长度�?/span>

例： char a[100],b[50]; memcpy(b, a, sizeof(b)); 注意如用 sizeof(a) �Q�会造成 b 的内存地址溢出�?/span>

Strcpy ��只能拷贝字�W�串了，它遇�?/span> '\0' ��q��束拷贝�?/span>

例： char a[100],b[50];strcpy(a,b); 如用 strcpy(b,a) �Q�要注意 a 中的字符串长度（�W�一�?/span> ‘\0�?/st1:chmetcnv> 之前�Q�是否超�q?/span> 50 位，如超�q�，则会造成 b 的内存地址溢出�?/span>

str 也可以用用个参数�?/span> strncpy(a,b,n)

========================================================

memset 主要应用是初始化某个内存�I�间�?/span>
memcpy 是用�?/span> copy 源空间的数据到目的空间中�?/span>
strcpy 用于字符�?/span> copy, 遇到 ‘\0�?/st1:chmetcnv> �Q�将�l�束�?/span>

如果你理解了�q�些�Q�你应该知道他们的区别：例如你初始化某块�I�间的时候，用到 memcpy �Q�那么应该怎么写，是不是显得很�W��?/span>
int m[100]
memset((void*)m,0x00,sizeof(int)*100);//Ok �Q?/span>
memcpy((void*)m,"\0\0\0\0....",sizeof(int)*100);//it’s wrong.
reference : http://hi.baidu.com/%B5%CE%C9%B3/blog/item/12025c2af5ffc33c5343c19f.html

snowball 2008-04-06 10:31 发表评论

Good C++ website

snowball — Wed, 02 Apr 2008 02:17:00 GMT

熊春��L��专栏
http://www.autodev.net/
http://blog.csdn.net/pandaxcl
杜中�?br />http://www.shnenglu.com/duzhongwei/
http://blog.csdn.net/win32asn
http://www.stlchina.org/
G9
http://blog.csdn.net/pongba/archive/2007/12/11/1930150.aspx

snowball 2008-04-02 10:17 发表评论