下面的代码，当用AfxBeginThread开始一个线程时，实际上是有内存泄漏的

如果不是unicode,某些中文字符会在不同的codepage上出现乱码;如果当前codepage为韩文时,某些中文字会变成韩文的样子,奇怪.

Step1: define _UNICODE, undefine _MBCS

宏定义UNICODE, _UNICODE定义两个也可以,定义一个也可以,windows的头文件会保证两个都会被定义.

Step2: 更改变量类型

比如 char -> TCHAR

但是 ,并不是说所有的char类型都不能用了.如果需要用,并且函数的参数/返回值什么的都不冲突,char类型还是可以用的.

Step3: 更改常量字符串形式

" abc " -> _T(" abc ")

因为开始写程序时没有注意 ,造成这样的常量字符串形式非常多,一个个改起来很烦,我写了个小插件,可以讲 ” abc ” 选中后点一下 button就能变成_T( “ abc ” ),有点用,代码也非常的短.

Step4: 替换某些函数

比如atoi -> _ttoi

在这里遇到一个问题,就是atof的替换.

按照msdn, atof应该被_ttof替换

但是奇怪的是,VC6里面不认识_tstof这个函数,VC.net 2003就可以.

有两个解决的办法:

1)      因为atof只是替换为浮点数,所以这里用WideCharToMultiByte转化一下之后再调用atof也是可行的

2)      呵呵,用strtod的替换函数_tcstod,哈哈,当然参数要变一下,我觉得这个方法不错,不要被msdn限制死了

Step5: 检查一下调用其他 dll 的接口函数

因为项目还用了另外一个dll,其中有些接口需要char*参数,这个时候就必须用WideCharToMultiByte转换一下了.

VC里面的设置:
1) 等把所有的编译error改完了之后一编译,除了个link错误,不过msdn有解释:
If you are using Unicode and MFC, you will get an unresolved external on _WinMain@16 if you don’t create an entrypoint to wWinMainCRTStartup. Use the /ENTRY option or type this value in the Project Settings dialog box. (To find this option in the development environment, click Settings on the Project menu, then click the Link tab, and click Output in the Category box.)

2)终于编译成功了,调试的时候却发现CString的值不能在QuickWatch窗口中显示了
tools->option->
in the debug tab u can find a check box Labeled "Display unicode strings"
Check it.

问题 : 直接用 ANSI 的 dll 中的 CString

在使用dll的时候,需要直接使用dll中的一个变量,是CString类型,因为这个dll还没有改为unicode,所以在直接使用其变量时有点问题,使得值不对.(是不是这个原因还没有完全验证,应该是的)

到这里 , 宣布移植失败 !

/*补充：
结果是失败，但是基本移植代码的所有步骤都有了。而且，也指出了如果需要调用的dll不是unicode，每次调用/传递参数时，都要转换，很烦。
后来我把dll的代码也移植了下，现在运行的很好，韩文、中文都可以显示，不管你当前语言是什么。
*/

还有一篇讲移植步骤的,更全面,适合更复杂的情况:
Cheat Sheet:Unicode-enabling Microsoft C/C++ Source Code (http://www.i18nguy.com/unicode/c-unicode.html)

现在好了，自己写了个程序，快速切换：当前是右手习惯就换到左手习惯；反之换到右手习惯
程序很小，只有2行代码：

struct CStringData
{
    long nRefs;             // reference count
    int nDataLength;        // length of data (including terminator)
    int nAllocLength;       // length of allocation
    // TCHAR data[nAllocLength]

    TCHAR* data()           // TCHAR* to managed data
        { return (TCHAR*)(this+1); }
};

class CString
{
public:
// Constructors

    // constructs empty CString
    CString();
    // copy constructor
    CString(const CString& stringSrc);
    // from a single character
    CString(TCHAR ch, int nRepeat = 1);
    // from an ANSI string (converts to TCHAR)
    CString(LPCSTR lpsz);
    // from a UNICODE string (converts to TCHAR)
    CString(LPCWSTR lpsz);
    // subset of characters from an ANSI string (converts to TCHAR)
    CString(LPCSTR lpch, int nLength);
    // subset of characters from a UNICODE string (converts to TCHAR)
    CString(LPCWSTR lpch, int nLength);
    // from unsigned characters
    CString(const unsigned char* psz);

// Attributes & Operations

但是看文章的样子，也不像是粗制滥造的，心里很是疑惑。
后来再打开VC7的源码看，果然：

看来微软在不知不觉中做了这么大的变化。

2
“string是方便的，可以从几乎所有的字符串构造而来，包括CString和char*； 
 CString次之，可以从基本的一些字符串变量构造而来，包括char*等； ”
的确，如下的代码是可以编译的：

但是这是表明string比CString方便吗？
实际上，在string sTest(strTest);中有一个函数被调用，就是：

然后才是string构造生成，这能说是string比CString方便吗？应该说是CString比string方便才好。
虽然可以用

来初始化CString，但是CString没有参数为string的构造函数，也是一个小小的遗憾，毕竟string是c++标准库的一部分了。

遇到好几个人说CMap在用CString做key类型时有问题，说用int和DWORD就可以，用CString就不行。因此很多人推荐使用MFC中的CMapStringToPtr之类。

看下面的代码：
//.h
    CMap<CString, LPCTSTR, int, int> typeMap;
//.cpp
    typeMap.SetAt(_T("ONE"),1);
    typeMap.SetAt(_T("TWO"),2);

    int nValue = 0;
    BOOL ret = typeMap.Lookup(_T("ONE"), nValue);
    ret = typeMap.Lookup(_T("THREE"), nValue);
    ret = typeMap.Lookup(_T("TWO"), nValue);
我的代码运行的很好，我觉得关键是ARG_KEY要选LPCTSTR