WINCE的编程忠告

最新推荐文章于 2022-06-20 14:38:23 发布

norains

最新推荐文章于 2022-06-20 14:38:23 发布

阅读量6.3k

点赞数

分类专栏： WinCE 文章标签： wince 编程 buffer mfc 编译器微软

本文链接：https://blog.csdn.net/norains/article/details/1523714

版权

WinCE 专栏收录该内容

193 篇文章 1 订阅

订阅专栏

//========================================================================
//TITLE:
//    WINCE的编程忠告
//AUTHOR:
//    norains
//DATE:
//    第一版:Wednesday 7-March -2007
//    修正版:Tuesday 7-October-2007
//
//========================================================================

1.尽量采用SDK!

  我不是那种偏执狂,全盘否定MFC,我也不是不知道MFC编写代码的便利,但我更知道,WINCE下的MFC,必须依赖于Explorer存在--恩,至少在WinCE 4.2下的确是如此.WinCE6.0呢?噢,对不起,我没试过,不知道.

  WinCE的可定制性,无法确保每一个OEM厂商一定采用Explore,也许他们会觉得Explorer太大了,又或许他们觉得自己写的shell更漂亮,但不管怎么说,Explorer是在他们的机器上小时了.如果你能想让你的程序能够在他们乃至大部分机器上耀武扬威,那么,请直接采用SDK书写代码吧!



2.不要在代码中出现奇怪的数字!

  奇怪的是数字?噢?什么是奇怪的数?

  我们来看看有段代码:

  TCHAR szFileRead[200] = {0};
  ...
  TCHAR szFileWrite[200] = {0};

  恩,现在看起来似乎没什么问题.但我们不妨考虑一下,时间这么一天天过去,很久很久以后,我们突然发现,szFileRead的200空间不够用了,需要扩充成300乃至更多.好吧,那我们就改吧:

  TCHAR szFileRead[300] = {0};

  噢,等等,为什么szFileWrite也是200,这个200和之前的szFileRead有没有联系?是否改了szFileRead也需要顺道更改szFileWrite?我的天,这是很久很久以前的事情,我怎么会知道呢?如果有文档记录,翻翻找找,也许尚存一线蛛丝马迹;如果没有呢,那我是不是已经点燃了一个定时炸弹?

  与其如此的担惊受怕,我们何必一开始不这么做呢?

  #define BUFFER_LENGTH 200
  TCHAR szFileRead[BUFFER_LENGTH] = {0};
  ...
  TCHAR szFileWrite[BUFFER_LENGTH] = {0};

  恩,这下子我们知道szFileRead和szFileWrite有那么紧密的联系了.即使以后修改,我们也不用每个每个逐字修正,只要更改BUFFER_LENGTH的定义就可以,这不是非常轻松愉快?



3.字符串?用宏定义的!

  回想一下,如果我们给某个窗口设置标题,是不是会这样:

  SetWindowText(hWnd,L"New_Wnd");

  是的,没错,这段代码在WinCE下运行得非常完美.但突然有那么一天,你的BOSS心血来潮,让你将该程序一直到WinXP,或是突然你觉得这段代码非常有用,想在WinXP下也秀一把,于是你无非这么做:复制 -> 黏贴 ->编译! Oh,我的上帝!瞧瞧,发现了什么?编译器无法通过!因为在VC6.0下,SetWindowText()的字符不能是宽字符!也就是说,代码应该换成这个模样:

  SetWindowText(hWnd,"New_Wnd");

  修正一下,终于顺利编译通过.好的,如果你的代码中只有一处,似乎更改一下并没有什么琐屑和烦恼,但想象一下,如果你定义了很多字符串操作:

  wchar_t szName[] = L"你好";
  wchar_t szNameAgain[sizeof(szName)];
  wcscpy(szNameAgain,szName);

  如果要把这段代码一直到WinXP,需要将wchar_t换成char,wcscpy置换为strcpy.啊,是不是非常烦琐?!万一更恐怖些,这种代码有上千行,那岂不是需要更改得头晕眼花?

  当然了,如果不想这么复杂,微软也给我们安排好了后路:

  TCHAR szName[] = TEXT("你好");
  TCHAR szNameAgain[sizeof(szName)];
  _tcscpy(szNameAgain,szName);

  这段代码无论在EVC或是VC6.0,编译器都会给你一个非常愉快的感受:EVC下TCHAR会自动转换为UNICODE字符,而VC下则不会.

  你能确保你的代码永远只能在WinCE下运行么?如果不能,当涉及到字符串的操作的时候,请使用微软为我们安排好的套餐吧!

  当然,这也有例外,如果你明确知道所使用的字符串无论在WinCE或是WinXP都是同样的类型,那么,请大胆的使用该类型吧.

  比如,最典型的例子,RS-232操作的某些蓝牙通信模块,它发回来的数据永远是ASCII码.如果此时,你是定义TCHAR来接收,在WinXP下工作得非常舒服,但WinCE下可能就会让你脑袋崩溃(原因请见之前的一句话)!这时候,你也只有唯一的选择,接收缓冲区毫不犹豫定义为:char!