被_T宏给坑了。。

TCHAR *sql = L"select * from mytable";
TRACE(_T("Message ID [8805] Sql [%s]. \n", sql);

仔细看TRACE 这样的代码竟然能编译通过。。
运行直接出错，这也太坑了，我觉得还不如直接L"123"这样呢。。
害我找了好久
难道为了移植都用_T 么。。
[解决办法]
习惯用_T，除非明确知道是UNICODE才用L，谁让你不仔细，把参数写到里面，我用_T都习惯先把_T("")写完再填其他的。
[解决办法]

引用:

Quote: 引用:

习惯用_T，除非明确知道是UNICODE才用L，谁让你不仔细，把参数写到里面，我用_T都习惯先把_T("")写完再填其他的。

一时眼花总会有的。。
我看大家都再用_T 我感觉也不错，以前一直用L，
但是今天早上改了程序就出错了，害我以为sprintf 哪里越界。。
这样的一个小小的疏忽 就足够浪费俩小时查到这个问题

我表示越小的疏忽 越是难找出错误 。。。表示曾深受其害
[解决办法]
TCHAR *sql = L"select * from mytable";
应改为
TCHAR *sql = _T("select * from mytable");
[解决办法]

引用:

Quote: 引用:

Quote: 引用:

习惯用_T，除非明确知道是UNICODE才用L，谁让你不仔细，把参数写到里面，我用_T都习惯先把_T("")写完再填其他的。

一时眼花总会有的。。
我看大家都再用_T 我感觉也不错，以前一直用L，
但是今天早上改了程序就出错了，害我以为sprintf 哪里越界。。
这样的一个小小的疏忽 就足够浪费俩小时查到这个问题

我表示越小的疏忽 越是难找出错误 。。。表示曾深受其害

同感啊，像switch漏掉1个break能让你迷糊好久，完全不知道错在哪里。
[解决办法]
宏这东西，不安全，尽量少！
[解决办法]
传说中价值几千万美元的bug:

x==2;