Shallow and biased, "C-language is dead."

Now, there are a lot of C + + programmers who are always pretentious and despise other developers. In fact, perhaps other people even more look down on him!

>> bias is always an individual, not a group. The author added the following sentence, no doubt that the biased is not a C + + programmer, but it is himself.

When I was a student, I was addicted to C + +, but to this day, I always can't write airtight C + + code, so I always think I will not C + +. Over the years, I've been looking for the best model for writing C + + code. But, to be honest, I have not seen a C + + programmer who has been known to be a master, nor have I seen a very-C + + code written good. C + + code is always ugly, bug-ridden!

The >> is even more absurd. Have you ever seen a good C + + code? The C + + standard library (STL) is so elegant. Moreover, there are so many classic C/s Open source works, as well as inadvertently leaked Windows NT core source, which is not a masterpiece? I feel sorry for the author shallow.

I have been programming in C for over 20 years. I have written c language compiler, C language debugger, with c development of other languages, games, client programs and server programs, you say! There is nothing I have not written. And my bookshelf is filled with k&r and Steele books with folded horns. I know the C language too well, but I hate him. Very annoying!

When I read a blog, the topic was "Why should every programmer learn C?" , I really had goose bumps. If you are really a professional programmer, you must think that this is a big joke, although the author's intention may not be the case. This rebuttal article is somewhat interesting, but it still fails to grasp the essence. So I started to say it. There are 5 reasons why those who can C and use C are not only supposed to use other languages now, but they should forget the annoying things they learn in C language.

1. Memory allocation

I could write a whole article about it, maybe write a book, or even write a piece of content that would fill the library's technical books. The existence of memory allocations and storage unit allocations is really a big hassle. You either have too little memory to allocate or too much memory to waste. The question here is: How do you initialize it to 0? or simply not initialize it. But the most scratching step is to free up memory. All existing toolkits will help you to confirm that you have released the memory of each of the previously allocated bits, never use it after the release, and will stop you, never release it two times. More seriously, the allocation of memory and release within the C language is very slow, very slow. When using memory allocation, I really don't even want to think about all the special situations that I have to think about, as long as the problem (object) is the right size, I prefer to use stack space or allocate the space beforehand. If I do this, I have something more to worry about. In other words, the man who invented the garbage processor deserved the Nobel Prize.

>> memory Management is the most classic topic in the program design. The GC is undoubtedly a great change in memory management, but I just think of it as a solution to memory management and not the only solution. A more elegant solution than GC is not necessarily. I prefer to choose the right memory management scheme in a particular situation, rather than having no choice, which is the great thing about C + +. All of those GC languages (such as Java, C #, etc.) impose this solution on programmers, which in some ways ease the burden on programmers, but also constrain the programmer's initiative. "Allocate memory and release within the C language is very slow"? Do not know where the author obtained the conclusion.

2, multithreading

I used to like the C language, really. Until I started to develop and maintain multithreaded servers in C. The C language does not provide a little bit of help for programmers to protect data for threads that conflict with the connection. Every intuition and experience you get from using a single-threaded day is wrong when it comes to multithreading. At least Java has a memory that represents synchronization keywords and documentation (but a very strange file), but even so, unless you use the new javax.concurrent, you can only collapse in front of the huge parallel machines. Back to C: in the simulated production environment, adhere to one weeks in the data center to debug a deadlock (it really happened). and Java just needs to ctrl+break! the sky!!!

There is really not much multithead support for the >> C + + language itself, which is expected to change after c++0x. However, keep in mind that C + + is always inclined to use a mature library to solve the problem.

3, pointers

The pointer is too hard to control, it's sinister; I don't even have a tactful way of describing it. A few months of my life have been used every year to debug those strange pointer problems. I used to try to get all the know-how, such as the hard to understand components, unions and offsets, and reuse the last two to mark, and all the other tricks. But I find that it's not worth it at all. Static references in other languages can be resolved.

>> pointer is too flexible embodiment of C/s + +. Code that uses pointers can be very ugly, but it can be elegant. --There is no difference in what language to use at this point. I believe that you can write elegant Java code, you can also write the same elegant C + + code. The converse is not necessarily (because some C + + paradigms are not supported by Java). It is confusing, but not necessarily inferior, that there are too many choices in C + + language. My advice to the C + + programmer is to learn more about and use the C + + standard library, rather than the details related to overly entangled pointers.