规范化的C++编程方法备忘录 c++ for windows

上面几贴的内容会很有用。后面说的假定你已经知道这些东西了。
这是一个复杂的系统，需要大量的人做不同的工作...

 

C++和Windows并无本质的联系，但个人认为在操作系统中，Windows的MSDN是C++/C中非常规范的典型例子，不像其他操作系统、非MS公司的windows软件那样，代码编写的随意性很大。本文旨在通过描述C++环境下的Windows API调用及MS官方的建议来表明规范的第三方软件接口是怎样实现的，如何正确使用。重要的是，如果我们自己也向别人提供API，我们的API至少应该编写成什么样子，才能让这些API的客户端能正确地工作。也为非windows系统及软件的开发提供参考。光靠铁杆fans的坚强意志和坚定信心及对其他产品的排斥是不能有效提高产品质量的。

一些基本问题先交代一下

    如果想让你的程序兼容性很好，代码的可移植性很关键。不经过任何修改，可以保证兼容于还没诞生的Windows；不经过任何修改，只需重新编译就可以运行于32位及64位平台上，还有各种Intel、AMD、Alpha平台。
如果你现在还选择C++/C这种“麻烦”的开发工具，“对技术的求知欲”不该是你唯一的理由。你想程序同时满足占内存小、快速运行、容易更快的使用系统API而不用坐等编程工具提供商升级他们的导出库，这不是大多数高级编程语言能够做到的。他们要么运行缓慢，将大量的时间耗费在和业务完全无关的检查、压栈出栈，使用大量的内存来完成同样与业务无关的逻辑相互作用和高级模块化上。计算机越来越快、软件却越来越慢、越来越大，而业务在其中的比例不可能很大，却可能很小...
（注意这和提高软件本身的健壮性是不同的，我们要避免的是昂贵而无用的各种检查、资源消耗行为，但提高软件质量的大量技术却不可少、越完善越好。虽然这两点间的区别有时很模糊）

 - 使用windows api的基本要求
1.保证使用的api被修改的可能性微乎其微。
    windows也是一个软件，和其他软件一样会不断升级。很多新的api被加入——尽管经过精心设计，不足依然可能存在。于是，有些api被废弃，还有些被修改或重新定位。大部分的api接口形式不变，但却被改变了行为。api的行为被修订的原因，主要有系统安全、系统内部结构、驱动及操控方式的改变等。无论怎样，以下解决方案总是有效的：
 1。不要假定api会执行在其描述文档未提及的实际行为。
 2。你最好有预言windows升级后对你调用的api的影响的能力，这种能力越强越好。尽量不要使用可能被改变或丢弃的功能。这样你的程序就具有较强的向后兼容性。不注意该点，当新版操作系统发布后，你的程序在其上很可能运行不正常、功能受限或根本不能运行。
  例如用过vista的，一定受过UAC的“折磨”...
 3。尽量使用各操作系统都具有的api及其通用的功能。这样你的程序就具有较强的向前兼容性。如果不这样，你就得做好放弃完全兼容的准备，你的程序在某些旧操作系统上运行不正常、功能受限或根本不能运行。
2.在遵循第一点的前提下，严格按照api说明文挡的要求使用该api。
例如，根据GetClientRect的描述文档，我们应该知道：
下面的代码

引用:
RECT rc;

GetClientRect(hWnd, &rc);
// Uses 'rc':
iW = rc.right - rc.left;
...

就要改成

引用:
RECT rc;

if(!GetClientRect(hWnd, &rc))
{
   // Reports error:
  ...
  return; // or throws an exception to a catcher.
}
// Uses 'rc':
iW = rc.right - rc.left;
...

3.考虑各种可能。如果有多个api可供选择以执行一样的功能，尽量使用不易被废弃、执行快、行为简单、可靠的api。举几个例子说明：
  用GetAncestor(hWnd, GA_PARENT)就比用GetParent(hWnd)好。原因可以通过比较这两个api的说明文档分析得到。
  用CreateWindowEx创建工具条比用CreateToolbar好。虽然后者简单，但已被废弃（我也不想这样，但没办法...）。
  用GetWindowLongPtr比用GetWindowLong好。通过查看导出表，可发现你的程序在32位编译版里只包含有GetWindowLong（这说明32位编译时GetWindowLongPtr是一个宏），但你的程序不用修改就可编译为64位版，照样运行正确。再则，LONG_PTR和LONG属于不同的两类整数。
4.对文档保留一些看法，当文档描述含糊时。因为有很多因素影响api的行为，文档含糊是因为很多细节问题不好交代，或者和很多具体情况交织在一起。一般情况下你可以采用纠错法编程，但如果有些特殊情况下的行为细节对你很重要，你得设法找到详细的官方文档（我必须警告你，它们可能很长，看起来要花上一些时间）来搞清楚。
  考虑到某些文档可能丢失，放一些常用API的说明如以后几贴。