Best practices for handling string in VC++?

Question

As I am new to Visual C++, there are so many types for handling string. When I use some type and go ahead with coding but on next step, there are in-build functions that use other types & it always require to convert one type of string to other. I found so many blogs but so confused when see so many answers & try but some are working & some are not.

Please give your answer or links that gives ultimate solution for handling different types of strings in visual c++.

Answer 1

That depends on what you are doing. Its a pain and no mater what you do you will have to deal with conversion.

• For the most case the std::string class will suite almost any need and is easly readable by anyone accustomed to c++.

• If you are using MFC cstring would be the most often seen and the normal choice

• For C++ Cli System::String is the standard

• All windows api that take strings expect null terminated cstyle string however depending on what frame work you are using you may not have to call many APi's directly especially if you are using .net

• I believe there is another couple of string classes in ATL but I have not used that library much.

Answer 2

The Win32 system APIs operate on LPCWSTR (pointers to C-style NULL terminated arrays of wchar_t). The system headers provide two versions of each API, for instance SetWindowTextA(HWND, LPCSTR) and SetWindowTextW(HWND, LPCWSTR) and a macro mapping SetWindowText() to the relevant one depending on the definition of UNICODE in your project ie:

#ifdef UNICODE
#define SetWindowText  SetWindowTextW
#else
#define SetWindowText  SetWindowTextA
#endif // !UNICODE 

The SetWindowTextA() API will build a temporary LPCWSTR from it's LPCSTR parameter and call SetWindowTextW() where the operating code is, so not using UNICODE and wchar_t in your code gets a performance penalty.

The COM interfaces are designed to operate on BSTR which are system allocated to be shared between different processes.

Happily a BSTR can be built from a LPCWSTR with th MS compiler provided _bstr_t class: _bstr_t myBstr(/LPCWSTR/ psText).

The ATL::CString and MFC CString classes (which share most of their code) use a same macro mechanism and are mapped to CStringA or CStringW. Both have a builtin operator (CStringA::operator LPCSTR() CStringW::operator LPCWSTR()) so you can pass a CString to a Win32 API:

CString myStr = _T("Hello");
::SetWindowText(myHwnd, myStr);

std::[w]string has no such built-in operator but a c_str() member which does the same:

std::wstring myStr = L"Hello"; // assuming UNICODE defined
::SetWindowText(myHwnd, myStr.c_str());

Summary:

1. #define UNICODE in all projects to avoid performance penalty on Win32 platforms.
2. If you use MFC you will naturally use it's CString class, if you use ATL or none you may use ATL::CString which is a standalone class (#include <atlstr.h> does not include the ATL library) or std::wstring.
3. If portability to other systems is a must you have to use std::wstring.

cheers, AR

Answer 3

Also, read http://www.codeproject.com/KB/string/cppstringguide2.aspx and the rest of that series to learn about string handling in C++. Yes it's horrible, this is (IMO) one of the worst shortcomings of C++.

Answer 4

In my opinion there are two ways to go. Use the STL std::string or std::wstring. Or use the MFC CString. If I'm writing MFC code I always use CString. It lets you use unicode by default if your system is setup to use it. However that being said there are a lot of older C/C++ functions that don't like the underlying datatype that unicode CStrings use. Most of them always have wide versions and it's a matter of finding the correct version to use. CStrings also have a ton of pre-built in functionality; IMO even more than the std::(w)string.

There is also BSTR if you plan on doing any COM development but I've rarely had to use that type of string before.