Use of MFC and STL

Use of MFC and STL

Zhao Xiangning

Problem:

I have read STL in several different places, but I still don't know whether STL or MFC is used in my application? My program also processes string, vectors, and so on. What is the difference between STL and MFC? Answer: Which one should I use ?" The answers to these questions are almost the same. It depends on what you want to do, the types of your applications, and your knowledge. Your C ++ certification is also important. When you need to do something quickly, it is best to use the tools you are most familiar. If you want to process text, and you are familiar with MFC, cstring is the first choice. If you are familiar with STL, use string instead of MFC. In this world, it doesn't matter which one you choose. Use string, list, or a large number of classes. But sometimes it takes time to say this or which system is better. For example, a subprogram recycle is used in a recent article, where STL is used. Why? When I started writing this program, I wrote it as an MFC console application-only because I have already written a template console application. But after reading the code again (you must also often encounter this situation ). I use both the cstring and cstringlist of MFC. Because the program needs to parse the command line parameters, recycle needs to create a list of names for deleting files. The file names are of the cstring type. It seems a waste of resources if you just link MFC to process strings and lists. The entire afxcoll. OBJ needs to be introduced to the cstringlist. The cstring needs to load strcore. OBJ, and afxwininit must initialize the required modules. If you don't read the ing file, you can't imagine what to load with MFC. In fact, I don't need to check it. I know that recycle should use STL more efficiently. To convert the program to STL and delete all the tracking code of MFC, I only need to modify a few lines of code. First, I # include <string> and <list>, and then add a type definition for convenience: // String list Typedef list <string> cstringlist; Only when the name is the same as that of MFC, the interface has completely changed. In particular, STL uses iterators instead of positions. Cstringlist files; // list of file names ... Cstringlist: iterator I; For (I = files. Begin (); I! = Files. End (); I ++ ){ ... } By comparison, I found that iterators of STL are easier to remember than positions of MFC. For some reason, I can't remember how to use positions. I always need to check the manual every time, and the begin/end and I ++ syntaxes are easy for me. On the other hand, I want STL TO HAVE A conversion function used to convert string to lpctstr, just like cstring: Cstring s; // MFC Lpctstr pstr = s; // call "cstring: Operator lpctstr () const ;" The Conversion Function of MFC is great. You can use it to upload a cstring to any C string that can pass pointers. You can write the following code: Cstring S = "whatever "; Myfunc (s); // myfunc wants the lpctstr If STL is used, you must explicitly call String: c_str. String S; Myfunc (S. c_str ()); Maybe STL designers think that conversion functions are easy to cause confusion. Indeed, this is precisely because it has created the entire STL design. Every time STL code is involved, the main problem is the type. A more important reason for using STL is portability. STL is part of the C ++ standard, just like printf, tolower, strcpy, and so on. I always feel that there are some problems with portability, because most programs depend on the platform. Other operating systems include Shfileoperation? No. However, try to minimize platform dependencies, and STL can help you. Any compiler that wants to be ANSI compatible must support STL. However, such support is not always adequate and successful. In particular, Microsoft regards STL as a burden, rather than treating it as a good technology. This is obviously unwise. On the other hand, to be fair, STL is indeed mysterious, manifested in its content division, generator and container. In addition, its template code is always inaccessible (a bit like ATL). Reading STL code poses a serious challenge to everyone. But UNIX programmers may have realized what STL contains. If you are familiar with STL's monotonous terms, unexpected function names, and highly generalized code, if you can control them, that is awesome. Soon you will be integrated into it and discover how powerful and easy to use STL functions are. STL follows UNIX system conventions, such as SED, awk, and emacs-hard to learn, but powerful and easy to use (I confess that Emacs is not used for killing ). For example If you really want to do some low-level programming, You should know STL! Where can I find more STL-related content? There are many sites on the network about STL. You only need to use "standard template library" or "STL" to search for the delimiter. The most famous site is: Http://www.sgi.com/Technology/STL/index.html You can find the document and FAQ pages that are easy to understand. Finally, I wish you a pleasant programming!