Why c ++?

Problem

Why c ++? Before you frown, try to answer this simple question. Efficiency, right? Everyone knows this. However, when a person starts to discuss programming languages or related topics, he must be very clear and targeted. Why? Let me ask you another question: if efficiency is the only reason people use C ++, why not use C directly? C is considered to be more efficient than C ++ (well, I know C is not much more efficient than C ++, so don't misunderstand what I mean here, even if they are the same in efficiency, the problem persists ).

 

Myth

I know that you have to say "Better abstract mechanism", because after all, C ++ is designed to be a better C. C ++ does not sacrifice efficiency, and has added so many advanced features. But the question is, "Do developers really need these advanced features ?". After all, we have been listening to kiss and other things. We have also heard that C is more kiss than C ++, so we need to use C cloud. This continuous debate has turned the comparison between C and C ++ into a big question (or confusion ). Surprisingly, it seems that many people prefer to use C. The biggest reason is that C ++ is too difficult to use. Even Linus thinks so.

 

The biggest impact of this phenomenon is that people tend to use C when balancing between C and C ++. And once people start to use C, they will soon be able to adapt and meet (in fact, this phenomenon exists in any language or even any human activity, and C ++ is also true, for example, I often hear people say that "I have been using XX language for so many years, and I have been using it well." According to this statement, no language with Turing Completeness can be used for programming yet ?). So even if they haven't tried c ++, or they haven't become good C ++ programmers, they start to claim that C is better than C ++. However, the real answer always depends on the actual situation.

 

Did I say "depends on the actual situation? What is the actual situation? Obviously, C is a better choice in some fields. For example, device-driven development does not require the OOP/GP skills. It's just a simple process of data. What really matters is that programmers know exactly how the system works and what they are doing. What about the write operating system? I did not develop any operating systems myself, but I have read a lot of operating system code (mostly UNIX ). I feel that a large part of the operating system does not require OOP/GP.

 

However, does this mean that C is a better choice than C ++ in all areas of efficiency? Not necessarily.

 

Answer

Let's analyze them one by one.

 

First, there are two efficiency-time efficiency (such as OS, Runtime Library, real-time applications, and high-demaning Systems) when people focus on efficiency) and space efficiency (such as various embedded systems ). However, such classification does not help us decide whether to use C or C ++, because C and C ++ have high space-time efficiency. The factors that really affect language selection are business logic (here "business logic" does not mean "enterprise application business "). For example, is it better to use OOP/GP to express logic (or code structure), or just use data and process?

 

From this point of view, we can roughly divide the application into two types (of course, the premise is to focus on C/C ++ rather than Java/C #/Ruby/Erlang ): underlying applications and high-level applications. The bottom layer here refers to areas where ob/OO and GP are useless, and the rest are at the top. Obviously, in all C/C ++ application fields (these fields require the efficiency of C/C ++ ), there are many high-level applications (you can check the list of Bjarne stroustrup on his homepage ). In these fields, abstraction is at least as important as efficiency. These are the applicable scenarios of C ++.

 

And so on. Even in fields where programmers do not need high-level abstraction, C ++ is never used. Why? It is only because your code does not use classes or templates. It does not mean that you cannot use libraries implemented by classes or templates. Because there are so many convenient C ++ libraries (and the upcoming tr1/tr2 ), I think there are good reasons to use C ++ in these fields-you can use only the C Core in C ++ during coding (Kiss in any way you like ), it can also use powerful C ++ libraries (such as STL containers, algorithms, and tr1/tr2 components ).

 

Finally, I think it is often overlooked that sometimes kiss is built on abstraction. I think Matthew Wilson explained this in the preface to his new book extended STL, Volume 1. He wrote two pieces of code, one using C and the other using C ++:

 

// In C

Dir * dir = opendir (".");

If (null! = DIR)

{

Struct dirent * de;

For (; null! = (De = readdir (DIR ));)

{

Struct stat 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 );

 

C ++ 09 is simpler:

 

// In C ++ 09

STD: for_each (readdir_sequence (".", readdir_sequence: files),: Remove );

 

That is to say, I think that even if a person does not need classes or templates in his own code, he has reason to use C ++, because the convenient C ++ library he used uses classes and templates. If an efficient container (or smart pointer) can free you from the boring manual memory management, why should we use the original malloc/free? If it is a better string class (I didn't mention STD: String, everyone on Earth knows that it is not the best string class made in C ++) or the regular expression class can free you from the code that processes strings that you don't want to read. Why do you need to do these tasks manually? If a "transform" (or "for_each") can use a line of code to handle the case, why do we need to write a for loop? If higher-order functions can meet your needs, why should we use clumsy alternatives? (OK, I know, the last two tasks that require C ++ to join Lambda support can really get rid of the nickname-this is exactly the task of C ++ 0x)

 

In short, I think kiss is not equivalent to "primitive"; kiss means to use the most suitable tool to do things, here, the most appropriate tool means that it can help you express your thoughts in the simplest way possible without reducing the readability of the Code, and keep the code easy to understand.

 

Real problems

People may say that C ++ (far from being used) is more likely to be used incorrectly than being used correctly. In contrast, the complexity of C Programs is easier to manage and control. In C ++, a common programmer may write a bunch of highly coupled classes, and the situation will soon become a mess. 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 is always a programmer in the class before understanding what is HAS-A and IS-A, dare to write again class, on the first floor of the stacked bedframe room, go over. They learned how to define classes and inherit class syntaxes in a specific language, and then they thought they had mastered the essence of OOP. On the other hand, this problem is more serious in C ++, because C ++ has so many accidental complexities that impede design, and C ++ is so flexible, there are several solutions to many problems in C ++ (think about so many GUI Libraries), so it is difficult to weigh these options. The non-essential complexity in C ++ is the burden of its history, c ++ 0x strives to eliminate these non-essential complexities (in this regard, C ++ 0x does a good job ). Flexibility is not a bad thing for design-it can help good designers make good designs. If someone complains that this is too brain-intensive, it may be a problem of the designer, rather than a strange language. Maybe he shouldn't be asked to design it. If you are worried that the advanced features of C ++ will lead your colleagues astray and screw up the project, then you may need to develop a code standard and implement it strictly (or you can follow the wisdom accumulated by the C ++ community over the years, or, if necessary, use only C or C with class in C ++, instead of avoiding C ++ because of risks (in fact, these risks can be avoided through some policies ), in that case, you won't be able to use those C ++ libraries.

 

On the other hand, a more important question is a psychological problem. If a language has a strange feature or a weak keyword, someone will discover it sooner or later, and someone will always be attracted to it, then let people get distracted from really useful things (this is a bit like the Murphy Law), not to mention those that may bring real problems (to some extent) the language of the beautiful solution is too good. In nature, people are prone to the temptation of rare resources. It is a rare resource, so it is easy to attract people's attention, let alone a skill that can make people feel very good in his circle. Step 4, you will find that even a waste of firewood technique can attract enough interest.

 

How many dark corners are there in C ++? How many skills are there in C ++? In general, how many non-essential complexities are there in C ++? (C ++ knows what I'm talking about)

 

In all fairness, most of the techniques found in recent years (in modern c ++) or (if you want to call them) are actually driven by actual needs, in particular, you need to implement highly flexible and universally applicable (generic) Class Libraries (such as those in boost ). These skills also (to some extent) provide beautiful solutions to actual problems. Let's think about it like this. If you are in a dilemma: either use the tricks and tricks to do something useful, or do nothing like this, no one else can use it. How do you choose? I know the heroes of boost have chosen the former-no matter how difficult, how abnormal, and how difficult it is, let it be done!

 

But none of these arguments can change the fact that we deserve a language that allows us to express our thoughts with clear code. To boost. function/boost. bind/boost. for tuple, variadic templates can greatly simplify the implementation of these libraries (reduced to almost 1/10 of the original code lines), while the code is also (FAR) more concise and easy to understand. Auto, initializer-list, rvalue-reference, template-aliasing, strong-typed enums, delegating-constructors, constexpr, alignments, inheriting-constructors, etc, all these C ++ 0x features share a common purpose-to eliminate non-essential complexity in multiple aspects of the language or embarrassment in the language.

 

As Bjarne stroustrup said, it is clear that C ++ is too complicated, and people are obviously frightened and don't need c ++ from time to time. But "People need relatively complex languages to solve absolutely complicated questions ". We cannot make it more powerful by reducing language features. Complex features, even templates, or even inheritance, are useful-if you need them right away, and if you are very careful about using them, do not use them to hit your own feet. In fact, among all the complexity of C ++, what really hinders us is "non-essential complexity" (some people call it "embarrassing "), instead of the programming paradigm supported by the Language (in fact, there are only three ). This is also the important reason why we should embrace C ++ 0x, because C ++ 0x is designed to eliminate the non-essential complexity that has long existed, at the same time, it also makes those tricks unnecessary (obviously, these skills pile up at the moment, turning over those C ++ books, or looking at the boost library, you will know what I'm talking about ), in this way, we can express our thoughts intuitively and clearly.

 

Conclusion

C ++ is difficult to use and is more difficult to use. So when you decide to use it, be careful and always remember your own needs and goals. Here is a simple guide:

 

Do we need high efficiency?

 

If necessary

 

Do we need to abstract it (please think carefully, because it is difficult to assess whether the use of C ++ advanced features can offset the risk of misuse of these mechanisms; the correct answer depends on how high the programmer level is, which encoding standards should be followed and how should they be executed )?

 

If yes, use C ++. If not, then,

 

Do we need to use the C ++ library to simplify development?

 

If yes, use C ++. But at the same time, you must always remember what you are doing-if your code does not require those "beautiful" abstractions, don't try to avoid getting into it. Don't just write code in the. cpp file and use classes and templates for C ++ compilers.

 

If not, use C. But why do you want to use C ++ as the core of C? Still the old reason: it is easy for people to fall into the "beautiful" Features of the language, even if they do not know whether these features are useful. I can't remember how many times I wrote a lot of classes and inheritance on my own. In the end, I would like to ask myself, "What are these classes and Inheritance ?". Therefore, if you can stick to the part that only uses C or C with class in C ++, and follow the idea of "keeping simple things simple; or if you need to migrate the C code to C ++, use C ++, but be very careful. On the other hand, if you do not need an abstract mechanism or a C ++ library, because it is very simple and does not require convenient components such as containers and strings, or you have determined that C ++ can bring very little benefits to the project, and it is not worth the risk, or not so many people can make good use of C ++, maybe you only use C.

 

Bottom line: Keep simple things simple (but remember that simplicity can be achieved through the use of advanced libraries); Use abstraction when necessary (remember not to abuse it; follow good design methods and best practices ).