About MFC and the use of STL

Problem:

I read about STL in several different places, but I still don't know if I am using STL or MFC in my application. My program also deals with string,vectors and other things. What's the difference between using STL and MFC?

Answer:

To answer, "which one should I use?" "The answer to this question is almost the same. It depends on what you want to do, the kind of application you have, and your knowledge. and your C + + accreditation is also important. When you need to do something quickly, it's best to take advantage of the tools you know best. If you want to process text, and you are familiar with MFC, CString is preferred. 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 bunch of classes to do the same. But sometimes it takes time to say this or which system is better. For example, in a recent article there is an example of a program recycle, in which I used the STL, for what?

When I started writing this program, I wrote it as an MFC console application-only because I had been applied by a written template console. But after looking at the code again (you're certainly going to get this too). I use MFC's CString and CStringList. Because the program resolves command-line arguments, recycle to create a list of names of deleted files, all of which are CString types. It seems a waste of resources to link MFC just to handle strings and lists. CStringList need to introduce the entire afxcoll.obj,cstring need to load strcore.obj, and afxwininit sure to initialize the required modules. If you don't look at the mapping file, you'll never imagine what MFC is going to load. Actually do not have to look at all, I knew recycle should use STL to be more efficient.

In order to convert the program to the STL and delete all MFC tracking code, I just need to change a few lines of code. First, I #include and, for convenience, add a type definition:

List of strings

typedef list CStringList;

Only the name is the same as MFC, and the interface has changed completely. 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++) {

...

}

In comparison, I found that STL iterators is easier to remember than MFC's positions. For some reason, I always can't remember the use of positions, always to check the manual, and Begin/end and i++ grammar for me. On the other hand, I want the STL to have a conversion function that converts a string to LPCTSTR, just like CString:

CString s; Mfc

LPCTSTR pstr = s; Invoke "Cstring::operator LPCTSTR () const;"

MFC's transformation function is great, using it to pass a CString to any C string that can be passed to the pointer. Allows you to write the following code:

CString s = "whatever";

MyFunc (s); MyFunc wants LPCTSTR.

And if you use STL, you must explicitly call STRING::C_STR.

string S;

MyFunc (S.c_str ());

Perhaps the STL designers think that the transformation function is easy to cause confusion, it is true, it is because of this to create the entire STL design. Each time as long as the STL code has been involved, the main problem is the type. One of the more important reasons to use STL is, of course, portability. STL is part of C + + standard, just like printf,,tolower,strcpy is part of C standard. I always feel that portability has some problems because most programs depend on the platform. Other operating systems have

SHFileOperation? No. However, as much as possible to minimize the degree of platform dependency, STL can help you do. Any compiler that wants to be compatible with ANSI must support STL. But this support is not always sufficient and successful. Microsoft, in particular, sees the STL as a burden, rather than as a good technique for treating it. This is obviously very unwise.

On the other hand, it is fair to say that STL is really mysterious, manifested in its content division, generator and container and so on. and its template code is always inaccessible (a bit like ATL), reading STL code is a serious challenge for everyone. But UNIX programmers may experience what the STL contains, and if you are familiar with the tedious terms of STL, the unexpected function name, and the highly generalized code, it feels great if you can harness them. Soon you'll get into it and find out how powerful the STL is and how easy it is to use it. STL follows UNIX system conventions, like Sed,awk and emacs--difficult to learn, but powerful and easy to use (I confess that I would never use Emacs to kill myself). If you really want to do some low-level programming, then know the STL bar! Where can I find more information about STL? There are a lot of websites about STL on the network. As long as the "Standard Template Library" or "STL" to search can find a lot. One of the most famous sites is:

Http://www.sgi.com/Technology/STL/index.html

You can find easy to understand documents and FAQ pages from above.