Why are there so many string types in MFC?

Tag: string , mfc Author: ok6sbsb7e Date: 2009-08-13
LPTSTR* arrpsz = new LPTSTR[ m_iNumColumns ];
arrpsz[ 0 ] = new TCHAR[ lstrlen( pszText ) + 1 ];
(void)lstrcpy( arrpsz[ 0 ], pszText );

This is a code snippet about String in MFC and there are also _T("HELLO"). Why are there so many String types in MFC? What are they used for?

Try reading this article for all the detail: johndcook.com/cplusplus_strings.html

Best Answer

Strictly speaking, what you're showing here are windows specific strings, not MFC String types (but your point is even better taken if you add in CString and std::string). It's more complex than it needs to be -- largely for historical reasons.

tchar.h is definitely worth looking at -- also search for TCHAR on MSDN.

There's an old joke about string processing in C that you may find amusing: string handling in C is so efficient because there's no string type.


Don't knock it. Writing unnecessary string classes and designing and then solving Y2K problems have kept the programming community in work for years! :-)

Other Answer1

Historical reasons.

The original windows APIs were in C (unless the real originals were in Pascal and have been lost in the mists). Microsoft created its own datatypes to represent C datatypes, likely because C datatypes are not standard in their size. (For C integral types, char is at least 8 bits, short is at least 16 bits and at least as big as a char, int is at least 16 bits and at least as big as a short, and long is at least 32 bits and at least as big as an int.) Since Windows ran first on essentially 16-bit systems and later 32-bit, C compilers didn't necessarily agree on sizes. Microsoft further designated more complex types, so (if I've got this right) a C char * would be referred to as a LPCSTR.

Thing is, an 8-bit character is not suitable for Unicode, as UTF-8 is not easy to retrofit into C or C++. Therefore, they needed a wide character type, which in C would be referred to as wchar_t, but which got a set of Microsoft datatypes corresponding to the earlier ones. Furthermore, since people might want to compile sometimes in Unicode and sometimes in ASCII, they made the TCHAR character type, and corresponding string types, which would be based on either char (for ASCII compilation) or wchar_t (for Unicode).

Then came MFC and C++ (sigh of relief) and Microsoft wanted a string type. Since this was before the standardization of C++, there was no std::string, so they invented CString. (They also had container classes that weren't compatible with what came to be the STL and then the containers part of the library.)

Like any mature and heavily used application or API, there's a whole lot in it that would be done completely differently if it were possible to do it over from scratch.

Other Answer2

See Generic-Text Mappings in TCHAR.H and the description of LPTSTR in Windows Data Types.


It should be noted that the official recommendation today is to ignore TCHAR, LPTSTR, _T(), and Unicode/ANSI switching macros, and use WCHAR, LPWSTR, L"..." and Unicode versions directly. The last version of Windows that did not support Unicode was WinME, and it is very unlikely for a typical application released today to have to support any of Win9x OS.
And that's especially true if the code is using functions like lstrcpy instead of functions like _tcscpy.