This article shows how CStdString, initially designed to replace the MFC CString, may as well smoothly replace WTL:CString, in any WTL project, including WinCE projects compiled with eVC4 SP4 or VS2005. The attached StdString.h is adapted from the last original revision dated 2005-Jan-10 for full WTL:CString and WinCE compliance.

The CStdString[X] classes

When including the attached StdString.h in your project, you access the class CStdString actually defined as either CStdStringA or CStdStringW, depending on your project Unicode/MBCS settings.

Note that getting rid of the _T() macros may be very handy for lazy typers like me, but costs, at runtime, the price of conversion if both side types are different.

Same WTL::CString interface

As defined in the attached StdString.h, CStdString exposes all WTL::CString constructors, operators, and function members with one difference: the CStdString[X] constructors that take a character and a count takes them in the order (count, value), which is the opposite of the order WTL::CString(TCHAR ch, int nLength) declares them.

Except for this constructor, call on CStdString any WTL::CString member, operator, and (LPCTSTR) cast, for instance:

WTL CString support

WTL 7.0 and over is designed to support one of ATL::CString or WTL::CString depending on the compile time conditions, some macro definitions, and the inclusion order of the headers; ATL::CString comes with ATL version 7.0; and VC++7.0 and over, eVC, and VCExpress/Platform SDK use ATL 3.0 and do not get it.

The following rules apply when _ATL_NO_AUTOMATIC_NAMESPACE and _WTL_NO_AUTOMATIC_NAMESPACE are both undefined:

WTL::CString is not compiled if you #define _WTL_NO_CSTRING before #include<atlmisc.h>

You will get ATL::CString support if you #include<atlstr.h> before #include<atlapp.h>

When ATL::CString is supported, WTL::CString should not be compiled.

If rule 2 does not apply, you will get WTL::CString support for classes defined after #define _WTL_USE_CSTRING

If rule 2 does not apply, you will get WTL::CString support for classes defined after #include<atlmisc.h>

Depending on rule 2, the _CSTRING_NS macro defined in atlapp.h will expand to ATL or WTL and silently map the application CString to WTL::CString or ATL::CString. So, we can write code like:

Plug-in CStdString as WTL::CString

To benefit the CStdString implementation of WTL::CStringand WTL CString support, unzip WtlStdString.zip files to a directory accessible by your compiler through angle brackets. The included atlssmisc.h will:

#include"StdString.h" (note the quoted file name),

define or declare in the WTL namespace, a class CString built on ::CStdString,

Comments and Discussions

I'm coming back again. This new trouble is already in the same dll project. I have a trouble using the latest revision of StdString in a VC++ Visual Studio 2005.
The project is a Win32 dinamic link library (old name in the Visual Studio 6.0 env.) SDK
based (no support for MFC/ATL is wanted).

I add a new resource: string table that store only one string. In an exported dll function simply I try to load this string into a CStdString variable.