[Celebrate National Day] Why do we have to learn and use C + + today? Reproduced

today, in a variety of new development languages, in Java and C #, why do we learn and use C + + today? Is it useful to learn C + + in the future? Is it all worthwhile to spend so much time and energy learning C + +? Are you learning C + + Money now? This is almost every C + + beginners will ask questions, in the choice of development language to learn, like the college entrance examination to fill the volunteer, will be a little confused. The following article Herb Sutter (in fact, a public speech on C + + and Beyond 2011) answered these questions nicely. All those students who are learning C + + and are confused about the future of C + + are worth reading. This article is reproduced, thank the original author Liu Weipeng, thank the translator WaterWall. More importantly, thanks to Herb Sutter. Here, there is also a discussion about this speech, can also refer to: http://www.cnbeta.com/articles/171221.htm

Why C + +?

Liu Weipeng (Pongba)/Wen

Waterwalk/Translation

The Louvre in C + + (HTTP://BLOG.CSDN.NET/PONGBA)

First thank you very much Waterwalk the hard translation :-) Waterwalk Huitie the translation in Original below, in order to facilitate reading I extracted the editor after the re-send a post. This article was originally intended to the recent C + + dispute System of the collation of some thinking, but because the beginning of the time in English written two paragraphs, and then simply all in English, causing a lot of people to read the trouble, in this sorry. But fortunately waterwalk translated the whole article, and then posted here alone :-)

Another, the original is here.

Problem

Why use C + +? Try to answer this simple question before you leave frowning. Efficiency, right? Everybody knows this. But the situation is that when a person starts talking about a programming language or a topic related to it, he must be very specific and targeted . Why is it? Let me ask you another question: if efficiency is the only reason people use C + +, why not just use C? C is considered more efficient than C + + (well, I know C is not much more efficient than C + +, so don't get me wrong here, because even if they're both efficient, the problem is still there).

Myth

I know you're going to say "better abstraction", because C + + is designed to be a better c. C + + does not sacrifice efficiency, and adds so many advanced features. But the question is, " do developers really need these advanced features?" ". After all, we've been listening to people talk about kiss and stuff like that. We have also heard that C is more kiss than C + + so we have to use C and so on. This ongoing debate will C with the C + + The comparison becomes a big puzzle (or chaos). Surprisingly, it seems that many people are more inclined to use C, the biggest reason is that C + + is really too difficult to use . Even Linus think so.

The biggest impact of this phenomenon is that people tend to use c when weighed between C and C + +. And once people start using C, they quickly adapt and meet ( in fact, in any language and even any human activity in this phenomenon,C + + , for example, often hear someone say "XX language I have used for so many years, has been used well ", according to this saying that any Turing complete language is not all can be used to program? ). So even if they haven't tried C + +, or if they haven't been a good C + + programmer Yet, they're starting to claim that C is better than C + +. In fact, however, the real answer always depends on the actual situation .

Did I say " depending on the situation "? So what is the reality? Clearly, some areas of c are better choices. For example, device-driven development does not require those oop/gp techniques. But simply processing the data, what really matters is that the programmer knows exactly how the system works and what they are doing. What about writing the operating system? I am not personally involved in any operating system development, but I have read a lot of operating system code (mostly Unix). My feeling is that a large part of the operating system does not require OOP/GP.

But does this mean that in all areas of efficiency and importance,C is a better choice than C + + ? not necessarily.

Answer

Let's analyze it one by one.

First, when people focus on efficiency, there are 2 efficiencies-time efficiency (such as OS, runtime libraries, real-time applications, high-demanding systems), and space efficiency (such as various embedded systems). However, this classification does not help us to decide whether to use C or C + +, because C and C + + are very efficient in space-time. The factors that really affect the choice of language are business logic (where the "business logic" is not meant for "enterprise application Business"). For example, is it good to use OOP/GP to express the logic (or the structure of the code), or just use the data and process?

From this point of view, we can broadly divide the application into two categories (assuming, of course, that the focus is on C + + rather than Java/c#/ruby/erlang, etc.): the underlying application and the high-level application. The bottom is where the ob/oo and GP are not useful, and the rest to the top. Obviously, in all the areas of C + + applications (these areas require C/+ + efficiency), there are a lot of high-level applications (see the list of Bjarne Stroustrup on his homepage). In these areas, abstraction is at least as important as efficiency. And these are the places where C + + is applicable.

Wait, there's. even in areas where programmers do not need advanced abstractions, they are not absolutely useless. C + + the . Why is it? simply because your code does not use a class or template does not imply a library that cannot be implemented with a class or template . Because there are so many handy C + + libraries (and the upcoming TR1/TR2), I think there's a good reason to use c++--in these areas. you can use only c in C + + when you encode Core (KISS in any way you like ), while also using powerful C + + libraries (such as STL containers, algorithms, and TR1/TR2 components).

Finally, I think people often overlook the point that sometimes KISS is also based on abstraction . I think Matthew Wilson has a good explanation for this in his new book, Extended STL, Volume 1. He wrote 2 pieces of code, one in C and the other in C + +:

//In Cdir* dir = Opendir (".");if(NULL! =dir) {  structdirent*de;  for(; NULL! = (de =Readdir (dir)); )  {    structStat St; if(0= = Stat (de->d_name, &st) &&S_ifreg= = (St.st_mode &s_ifmt)) {Remove (de-d_name); }} closedir (dir);}//In C + +Readdir_sequence Entries (".", Readdir_sequence::files); Std::for_each (Entries.begin (), Entries.end (),;: Remove); //and it's simpler in c++09://In c++09Std::for_each (Readdir_sequence (".", Readdir_sequence::files),:: Remove);

In other words, I think that even if a person does not need a class or template in their own code, he has reason to use C + +, because he uses the convenient C + + library for classes and templates . If an efficient container (or smart pointer) can free you from boring manual memory management, why use the original malloc/free? If a better string class (I don't say std::string, the Earth people know that it's not the best string that can be made in C + +) or the regular expression class can get you out of a lump of code that you don't want to see. So why do you have to do these things manually? If a "transform" (or "for_each") can get things done beautifully in one line of code, why write a for loop? If higher-order functions meet your needs, why use clumsy alternatives? (OK, I know, the last two need to add lambda support to C + + to really get rid of the stigma--this is the task of c++0x)

in short, I think KISS is not the same as " Original " ; KISS means to do things with the most appropriate tools, here " most suitable " means that tools can help you express ideas in the simplest possible way, without compromising the readability of your code, and keeping your code easy to understand.

The real problem

One might say that C + + (FAR) is more prone to mis-use than being used correctly. In contrast, the complexity of C programs is easier to manage and control. In C + +, a normal programmer would probably write a bunch of highly-coupled classes, and soon things would get messy. But this is actually another problem. On the other hand, this kind of thing is also likely to happen in any object-oriented language,because there are always programmers who still don't understand whathas-aand theis-aofbefore, dare to write again class on the class, duplication layer by layer of stack up. They learned how to define classes in a particular language, how to inherit the syntax of classes, and then they thought they had masteredOOPthe essence of the。 On the other hand, this problem is more serious in C + +, because C + + has so many accidental complexities in the design, and C + + is so flexible, many problems in C + + have several solutions (think of so many GUI library bar), so the tradeoff in these choices itself becomes a difficulty. The non-essential complexity of C + + is a historical burden, and c++0x is trying to eliminate these non-essential complexities (c++0x's work is really good in this regard). Flexibility is not a bad thing for design-it can help good designers make good designs. If someone complains that this is too much of a brain cell, it could be the designer's problem, not the language. Maybe he shouldn't have made the design. If you're worried about the advanced features of C + + that will lead your coworkers astray and screw up the project, youPerhaps you should develop a coding standard and implement it rigorously (or you can followthe wisdom that the C + + community has accumulated over the years, or if necessary, use only theC + +in theCorC with Classthat partInstead of avoiding C + + because of the risk that these risks can be avoided by some policies,because then, you won't be able to use thoseC + +'s library.。

On the other hand, a more important question is a psychological one--if there is a singular feature or nook in a language, then sooner or later someone will find it, someone will always be attracted to it, and then distract people from something really useful (something like the Murphy rule). , not to mention the language nook that has the potential to bring (to some extent) beautiful solutions to real problems. people are inherently vulnerable to the temptation of scarce resources. Artifice is a scarce resource, and Yu Shichi is apt to attract attention, not to mention a skill that can make the person feel very good in his circle . Step back 10,000, and you'll find that even a scrap-wood technique can be of interest to people.

C + + How many dark corners are there in it? How many tricks do you have in C + +? In general,what is the non-essential complexity ofC + + ? ( someone who knows a certain C + + must know what I'm talking about)

To be fair, most of the techniques discovered in recent years (in modern C + +) or (if you want to call them) technology are actually driven by real needs, especially those that require highly flexible and universally applicable (generic) libraries (for example, those in boost). And these techniques do (to some extent) provide a beautiful solution to real-world problems. Let's think about it, if you're in a dilemma: either use those artifice to do something useful, or do it without others. How would you choose? I know that the boost heroes have chosen the former--no matter how difficult and how perverted and nasty it is to make it!

but none of these arguments can change the fact that we deserve a language that allows us to express our ideas clearly in code . Taking Boost.function/boost.bind/boost.tuple as an example, variadic templates can greatly simplify the implementation of these libraries (down to almost the number of lines of code that were originally 1/10 ), and the code is (FAR) more concise and understandable . Auto,initializer-list,rvalue-reference,template-aliasing,strong-typed enums,delegating-constructors,constexpr, Alignments,inheriting-constructors, et cetera, all of these c++0x traits have a common purpose -- Eliminate the manifold non-essential complexities of language or the embarrassment of language .

As Bjarne Stroustrup said, it is clear that C + + is too complex, and it is clear that people are terrified and are not using C + + any time. But " people need a relatively complex language to solve the absolutely complex question ." we cannot make it more powerful by reducing the language characteristics . Complex features even more than templates are useful-if you just need them, and if you use them with extreme care, don't foot. in fact at all C + + of complexity, what really hinders our " non-essential complexity "(some call it" awkward "), not the programming paradigm supported by language (in fact , 3 ). And that's why we should embrace c++0x, because c++0x is trying to eliminate the non-essential complexities of the long-standing, and also makes those artifice unnecessary (obviously, these techniques are now piling up and flipping through the C + + Books, or look at the boost library, you know what I'm talking about, so that we can express our ideas visually and clearly .

Conclusion

C + + is hard to use. So when you decide to use it, be careful, always remember your needs and what you want to achieve . Here's a simple guide:

Do we need to be efficient?

If necessary, then

Do we need to be abstract (consider this carefully because it is difficult to assess whether using C + + Advanced features can counteract the risk of misuse of these mechanisms ; the correct answer depends on how high the programmer's level is, What coding standards are followed and how the coding standards are performed, etc. )?

If it is, then use C + + bar. If not, then,

Do we need to use C + + libraries to simplify development ?

If it is, then use C + + bar. But at the same time you must always keep in mind what you're doing-if your code doesn't need those "pretty" abstractions, don't try to avoid getting caught in it. not just because you're here . . cpp write the code in the file and you use the C + + The compiler will use the class Ah, template ah these things .

If not, then use C, but why would you want to do more than just use C in C + + 's part of the core? Or the old reason: it's easy to get caught up in the "pretty" nature of language, even if they don't yet know if these features are useful . I can not remember how many times I wrote a lot of classes and inheritance, to finally ask myself " what kind of class and inheritance do you want to do? ". So, if you can stick to the part of C or C with Class in C + + and follow the " The idea of keeping simple things simple , or if you need to migrate C code to C + +, use C + +, but be very careful. On the other hand, if you don't need an abstract mechanism, you don't need C + + Library, because things are very simple , do not need convenient components such as containers and strings, or you have decided that C + + can give a project a negligible benefit, not worth taking risks, Or simply not so many people can use C + +, then you may still only use C 's good .

The bottom line is: keep simple things simple (but also keep in mind that simplicity can be obtained by using an advanced library), use abstractions when necessary (remember not to misuse; follow good design methods and best Practices ).

[Celebrate National Day] Why do we have to learn and use C + + today? Reproduced