STL String class What's up? _c language

STL String class What's wrong? Chenhao

Objective

Last weekend, when I was chatting with my classmates about the fragrant hills, the classmate said that the string class in the STL had tortured him before he developed a system a few years ago, and then, as the complexity of the program deepened, he almost lost confidence and trust in the string class. He felt he was confused to string class. To be honest, I had the same pain a few years ago (when I wrote down the standard C + + string Copy-on-write technology). At that time, I had to study that it was not at all SGI produced by the source of the string, the code is almost zero readability, and as the more in-depth understanding, the more I think the C + + world is full of traps and defects. It is increasingly felt that sometimes those classes do not work as they think they are.

Why is this happening? The string class is just a "simple" class, what if it's a more complex class? Over the years, the C + + camp has denounced standard string classes in standard template libraries as being increasingly fierce. The C + + camp's contention for this "kid" has not stopped. It is believed that there will be a big change in the string class when the next C + + standard is introduced.

Understanding String Classes

Before we look at what's wrong with the string class, let me start by saying how to understand a C + + class. We want to understand a C + + class, in general, to start from three aspects.

I. Intention (intention). Knowing the reason why, what is the purpose of the string class? Only by understanding the intention, we know its thinking. This is the most important and fundamental part of understanding a thing. Otherwise, you will find that it does not behave as you expect. The string class has two meanings, the first is to handle an array of char types, and encapsulates some string-handling functions in standard C. And when the string class goes into the C + + standard, its second meaning is a container. These two things are not contradictory, we need to understand the mechanism of string, which needs to be considered from both aspects.

Second, the specification (specification). We notice that the string class has too many interface functions. This is the current C + + camp to denounce its most important topic. A small string class actually has 106 member interface functions. Actually, the C + + Standards Committee will tolerate this "ugly" thing happen? At present, the main reason for the "C + + Standard Committee Brain" is two points, one is to improve efficiency, the other is for common operation.

1 Let's look at efficiency first, and see the "= =" operator overloaded interface in the String class:

BOOL operator== (const string& LHS, const string& RHS);
BOOL operator== (const string& LHS, const char* RHS);
BOOL operator== (const char* LHS, const string& RHS);

The first one was standard, and the last two seemed to be unnecessary. If we call: (Str = "string") without the next two interfaces, the string constructor will convert the char* "string" to a string object, and then call the first interface, which is operator== (str, String (" String ")). Such "redundant" designs can only be said to be efficient, in order to save time (which saves a lot of time) by calling construction/destructor and allocating/freeing memory. In the following two interfaces, the strcmp function of C is used directly. So it seems that this design is still necessary. There are many algorithms and designs for efficiency in the string class, such as: Copy-on-Write (see my standard C + + class string Copy-on-Write technology). These things make our string very efficient, but it also brings a trap. If you do not know these things, then when you use it unexpected problems occur, you will be confused and overwhelmed.

2 Another reason for a string class to have such a large interface is the common operation. such as the substr () of the String class, which is a function that intercepts a substring. This function is not needed because a string has a constructor that can specify its start and length to construct itself from another string class to achieve this function. There is also the copy () function, which is also a function that is not necessary to copy the contents of the string class into a memory buffer, a method that has proved very rarely used. Probably, 1) for security purposes, it is necessary to have such a member to replicate the content; 2 The designer thinks copy is more beautiful than strcpy or memcpy. Copy () is less necessary than substr ().

III. implementation (Implementation). C + + standard does not have too much intervention to achieve. Different production chambers have different implementations. Different chambers of commerce consider whether one of the things in the standard meets the needs of the market, and consider whether their compilers have the ability to compile standards. As a result, they are always slightly or subversive to revise the standard. C + + In compiler differences are painful and hopeless, if you do not understand the specific implementation, when you use C + +, you will also find that it does not work as you think.

Only from the above three aspects, you can really understand a C + + class, and you can use C + +. C + + Experts are from such three aspects of C + + reality analysis of various classes, and to verify the C + + class design.

What is wrong with the string class?

The string class is actually pretty good. Its design is very technical content. It has high efficiency, fast running speed and easy to use. It has plenty of interfaces to meet a wide variety of methods and is flexible to use.

However, this string seems to be a bit not with the times, it is now designed to maintain the appearance of the 10, 10 years, the entire technical environment has been a lot of changes, people also in the process of using C + + has been allowed a lot of experience. For example: Now almost all of the programs are running in a Tanjin/threading environment, and 10 years ago the mainstream is only the application of the/thread, which is a huge change. In recent years, the C + + camp has also achieved a lot of experience in practice, especially template technology, and our STL obviously failed to keep pace.

The first is the string class, the current C + + camp on the string category of denunciation mainly focused on the following aspects. For the following questions, the C + + camp is still arguing. However, as a good programmer, we should pay attention to these aspects in our design and programming.

1 the current standard string class has 106 interface functions (including constructs and destructors), and if the default parameters are considered, then there are 134 different interfaces. There are 5 function templates that produce infinitely many different functions. There are also a variety of performance optimizations. In so many member functions, a lot of redundancy is unnecessary. Worst of all, many programmers do not understand them, either to waste their advantage or to trample on the pitfalls.

2 Many people think that some of the functions provided by the string category are not, and are redundant. The string class is implemented multiple times on the same feature, but some features are not implemented. Such as: Case insensitive comparisons, wide line character (W_char) support, and character char data interfaces, and so on.

3 as an STL container, the string class and the design are basically the same as other containers. These STL are not encouraged to be inherited. Because the designers of STL containers have almost forgotten the use of virtual functions, which prevents polymorphism, perhaps this is also a design designed to consider efficiency and performance. For a design that is easy to STL, most people agree. But for the string class, many people believe that the string class is a special class, and that the string class should be given special care, given the frequency with which it is used.

4 There are also many people think that the standard STRNG class force dynamic memory allocation (malloc), that is even a very short string. This results in a memory fragmentation problem (we know that the memory fragmentation problem will take malloc a long time to return, due to reduced performance throughout the program.) As for the memory fragmentation problem, this is a serious problem and there is no good way to do it now except to restart the application. They believe that the design of the string class exacerbates the memory fragmentation problem. They wanted the string class to have its own stack of memory to hold some short strings, without having to always allocate memory on the heap. (since the string used for a string class is almost never long)

5 The implementation of many string classes, all using the Copy-on-write (COW) technology. Although this is a very efficient technology. However, because of the sharing of memory, resulting in the program in a "multi-threaded" environment and prone to errors, if the string instance in two threads share the same memory, it is likely to occur potential memory problems (see my standard C + + class string Copy-on-write technology) The last section is an example). This technology is likely to be removed from the next version of the standard. (and some newer versions of the STL do not support cow, such as the STL under Microsoft VC8.0)

6 The standard string class does not support error handling for Policy-base technology. String simply throws an exception when it encounters an error. Although this is a standard, there are some cases where exceptions (gcc–fno-exception) are not used. In addition, it is not possible to require all programs to try catch when using string operations, a better approach is that the string class encapsulates its own error-handling function and allows the user to define which error handling mechanism is needed.


Because the string class is unsatisfactory, especially with 106 interface functions that are difficult for many people to accept, many people are writing their own string class. In general, however, the standard string class is a difficult class to distinguish between good and bad. Whether you're a senior-level programmer or not, you'll use it. Like the whole C + +, it is a double-edged sword, in most cases, it is still worthy of our trust.

At present, there is a lot of controversy over the string category. The C + + Standards Committee also said: "The C + + Standard is the best we could make it." If we could have agreed on it better, then we would have made it better. " In C + + such a messy territory, although the STL is not perfect, but compared to say, he still looks so beautiful and fine speech.

Postscript

When it comes to the end of the C + + article, I'm going to do it again. C + + This world is very complex and dangerous. A small string class in this article alone can cause so much discussion, not to mention other classes?

Let's boldly wonder if C + + is really a high-level language? The current C + + need to use his people have a considerable level of expertise, and hope that the high level of people seems to be contrary to the development of technology. A good development language is one that makes it easy for people to focus more on business logic. and C + + This language requires technical staff than to live C has a more advanced and professional technical knowledge and ability.

Did we confuse the "ignorance" of string with our program, or the design of the string class that messed up our program? is C + + own software development to get a mess? Or do you use C + + to make a mess of them? It seems to be a combination of both, but we know that both the C + + Standards Committee and the developers, the future of C + + is still a long way.

(please indicate the author and the source when you reprint.) Do not use for commercial purposes without permission more articles please visit my Blog:http://blog.csdn.net/haoel