趁着双十一买了好几本想买的书，其中就有这本《Windows 核心编程》。首先需要吐槽的就是好好的《Windows via C/C++》这么高端大气上档次的名字怎么就被翻译成了这么个蛋疼样，而且中文版的封面也是扑面而来的一股浓郁的上个世纪气息，以至于在正文里看到 Vista 的字样都感觉各种穿越……

本文是关于这本书的第一篇读书笔记。天知道会不会有第二篇。

虽说之前已经写过好几篇关于字符编码的文章，都快写吐了，不过读了这本书的开篇还是感觉相见恨晚。这里对于前面这几篇里关于字符串的说明进行一下查漏补缺。

Unicode 和 UTF-16

前文书说到，Unicode 定义的是码位（Code Point），即为每一个字符赋一个唯一编号，记作 U+XXXX。Unicode 目前实际占用了 0₁₆ 到 10FFFF₁₆ 的码位，有些已经分配了字符，有些还没有。

Unicode 中最初推出的 U+0000 到 U+FFFF 这 2¹⁶ 个码位称为基本多文种平面（Basic Multilingual Plane，BMP）。早年只有这一个平面的时候，Unicode 与 UTF-16 是等价的，因为可以做到一一对应。然而时过境迁，区区 16 位已经满足不了 U+10000 到 U+10FFFF 的码位了。

与 UTF-8 编码规则的爽快不同，UTF-16 在沦为实实在在的「编码」时，还需要考虑到向后兼容性问题。如何在维持 U+0000 到 U+FFFF 一一对应的同时，把剩余的 U+10000 到 U+10FFFF 编进来？

答案是：把 U+D800 到 U+DFFF 命名为 UTF-16 编码专用字符。即如果 UTF-16 数据流中出现了这一范围内的字符，意味着它本身不是一个字符，紧接着它的 16 位数据需要加上一定的偏移值才是真正的数据。

这一土豪做法让我目瞪口呆。至于 UTF-32，目前来说与它与 Unicode 码位一一对应起来绰绰有余。当然，如果哪天发现了外星文明，需要把他们的字符也编码进来，导致 Unicode 占用的码位暴增，说不定这一一对应的任务就只能交给未来的 UTF-64 了。这就是把问题留给子孙后代去解决的大智慧啊！

CHAR 和 LPSTR

前文书里吐槽过 Windows API 的丑陋不堪，也说过这也是历史遗留、不得已而为之。

没错的，CHAR 和 char 在语义上并不等价，前者专指 8 位字符，后者则只是字符而已，说不定在哪个古董机器上就是 7 位了。（尽管我不认为你会在那上面跑 Windows……）

而 LPSTR 尽管被定义为 CHAR *，但它实际上还借助了编译器扩展实现了「以 NUL 结尾」的语义：

typedef __nullterminated CHAR *LPSTR;

Unicode 和 ANSI 版本

说实话我依旧不喜欢官方的这两个名字，我更喜欢「宽字符版本」和「多字节字符版本」这两个更拗口但更准确的名字。

由于现代 Windows 内部都是以 UTF-16 存储（承袭自 UCS-2），实际提供的 API 本身也都是 Unicode 版本的，即以 W 结尾的版本。而相应的 A 结尾的 ANSI 版本则是在 W 版本基础上的封装。

于是可以想象，全局使用 ANSI 相比全局使用 Unicode 而言要占更多的内存，理论上也要更慢一些。

以上。

本文源自于今天对 neuront 童鞋的这篇文章的末尾的那段代码的 C++ 实现的思考。（好多「的」……）

尽管 std::accumulate() 和 Python 的 reduce() 类似，但因为 C艹 的 std::map<std::string, std::map<std::string, int>> 和 std::map<std::string, int> 是不同的类型，所以似乎只能自己用可变参数模板写一个了。

简单起见，我们还是退一步，来解决一个更简单、更不通用、而且似乎和 reduce() 完全无关的问题吧：如何才能一次性取得任意层次的字典值？用更直白的代码表达，就是我们需要一个 GetMapValue() 函数，实现这样的功能：

// 用于缓解眼花缭乱感的宏
#define MAP_LITERAL(...) { __VA_ARGS__ }

// 简单映射
std::map<std::string, std::string>
simple_dict = MAP_LITERAL({"Hello", "World"});

// 「我勒个去居然这么麻烦」映射
std::map<std::string,
         std::map<std::string,
                  std::map<std::string,
                           int>>>
nested_dict = MAP_LITERAL( { "x", MAP_LITERAL( { "y", MAP_LITERAL( { "a", 10 } ) },
                                               { "z", MAP_LITERAL( { "b", 20 } ) } ) });

auto value1 = GetMapValue(simple_dict, "Hello");
std::cout << value1 << std::endl;

auto value2 = GetMapValue(nested_dict, "x", "y", "a");
std::cout << value2 << std::endl;

初始的版本

初步分析，GetMapValue() 需要接受一个 Map 以及至少一个 Key。如此，参数可变，首选 C++11 的可变参数模板。一次性将所有 Key 拿到手后，每次用第一个 Key 获取下一级 Map，而后用余下的 Key 递归，最终获取所要的值。而要写递归，最好先从最简单的情况写起。

template <typename MapType>
auto GetMapValue(MapType const& map, typename MapType::key_type const& key)
    -> typename MapType::mapped_type
{
    return map.at(key);
}

鉴于本人目前对于右值引用还不熟悉，就只用 const& 了（& 只能引用左值；const& 既能引用左值、又能引用右值，但无法修改）。

这里需要注意的是 STL 的几种 Map 里 typedef 到的数据类型，略坑：

• key_type 是 Key 的类型
• mapped_type 是 Value 的类型
• value_type 是 Map 中实际存储的键值对的具体类型（如 std::pair<key_type, mapped_type>）

不过这样一来，我们的 GetMapValue() 就可以在 STL 的这几种 Map 里通用了。

不被支持的递归 decltype 模板

本来我想，递归版本按照上面这个最简版本写一下就 OK 了。可变参数模板的基本用法我以前的日志有写过；这里唯一麻烦的是返回值，因为通用性，只有最终被调用的版本才知道确切的返回值，不过 decltype 似乎可以救场：

template <typename MapType, typename... MoreKeyTypes>
auto GetMapValue(MapType const& map, typename MapType::key_type const& key,
                 typename MapType::mapped_type::key_type const& anotherKey, MoreKeyTypes... moreKeys)
    -> decltype(GetMapValue(map.at(key), anotherKey, moreKeys...))
{
    return GetMapValue(map.at(key), anotherKey, moreKeys...);
}

然而，编译器不给面子，直接提示模板推导失败，decltype 时找不到接受两个 Key 版本的 GetMapValue()（三个参数）。

似乎，decltype 是不支持递归调用的，亦或者推导时自身还不存在。decltype 以及模板的一些规则真心还不是很熟，所以暂时没有找到真凭实据。

Traits

于是我终于知道为什么世界上会有 Traits 这种东西存在了。（比如 std::basic_string 的模板参数之一就是 class Traits = std::char_traits<CharT>。）Traits 是用来描述某个类型周边信息的东西。这里，我们需要一个 Traits 来计算一个 Map 被使用若干次 Key 后的 Value 类型。

那么很显然的，这个 MapTraits 依旧是可变参数模板、依旧是递归实现。

template <typename MapType, typename KeyType, typename... KeyTypes>
struct MapTraits
{
    typedef typename MapTraits<typename MapType::mapped_type, KeyTypes...>::mapped_type mapped_type;
};

template <typename MapType, typename KeyType>
struct MapTraits<MapType, KeyType>
{
    typedef typename MapType::mapped_type mapped_type;
};

完全体

不出所料，最终的代码是一番如此纠结的景象。看这样的代码眼睛压力山大。

template <typename MapType>
auto GetMapValue(MapType const& map, typename MapType::key_type const& key)
    -> typename MapType::mapped_type
{
    return map.at(key);
}

template <typename MapType, typename... MoreKeyTypes>
auto GetMapValue(MapType const& map, typename MapType::key_type const& key,
                typename MapType::mapped_type::key_type const& anotherKey, MoreKeyTypes... moreKeys)
    -> typename MapTraits<typename MapType::mapped_type, typename MapType::mapped_type::key_type, MoreKeyTypes...>::mapped_type
{
    return GetMapValue(map.at(key), anotherKey, moreKeys...);
}

完整的测试代码见这个 Gist：https://gist.github.com/timothyqiu/6877974

Traits 的小插曲

我第一次写的时候，把 MapTraits 的特化形式写成了这样：

template <typename MapType>                             // 正式版本: typename MapType, typename KeyType
struct MapTraits<MapType, typename MapType::key_type>   // 正式版本: MapType, KeyType
{
    typedef typename MapType::mapped_type mapped_type;
};

其实只是用 typename MapType::key_type 替换了一个正式版本里的模板参数 KeyType 而已。这样做其实也并非不可，只不过产出的是「高标准、严要求」的代码：

// 正式版本可行，但是在这个版本里一堆模板错误
auto value2 = GetMapValue(nested_dict, "x", "y", "a");

// 两个版本都可行
auto value2 = GetMapValue(nested_dict, std::string("x"), std::string("y"), std::string("a"));

原理大致是，这个版本因为把特化形式的第二个模板参数固定成了第一个参数的 key_type，所以如果使用了和 key_type 不同但是可以隐式转换的类型，会导致模板推导失败。

C 语言中的字符串

抽象数据类型

C 语言贴近机器模型，所以并不提供字符串数据类型。但是，字符串却在 C 语言中作为 ADT 存在着：使用字符指针代表字符串，同时提供了 string.h 作为字符串的操作库，而在实际存储时则使用字符数组。

虽说单引号引起的字符是该字符对应的一个整型常量，但是 'A' 和 65 没有任何关系。因为 C 语言并没有要求每个实现都用 ASCII 字符集作为执行字符集。

事实上，C 语言标准要求每个 C 语言实现都要定义两个字符集：代码字符集、执行字符集。每个字符集又都由基础字符和扩展字符构成。扩展字符可有可无，完全由该实现所支持的区域设置决定；基础字符只划定了字符，字符对应的码位留由实现决定。

字符与 char 类型

字符集顾名思义就是字符的集合，字符集除了划定所包含的字符外，还将其所包含的字符按照一定顺序编号，这样的编号称作码位。著名的 ASCII 参照已有电报报文设计，分别用数字 0 到 127 作为英文大小写字母、阿拉伯数字、标点符号等的码位。由于出现早、使用广，后辈字符集、字符编码几乎都与之兼容为荣。

然而 ASCII 本身并不完美，尽管名字叫「美国信息交换标准代码」，但是却连英语中的一些诸如 naïve、café、élite 的外来词都无法表示，欧洲各国那些稀奇古怪的字母就更别提了。所幸，我们很快来到了一个字节 8 位的年代，char 能够容纳 0 到 255 一共 256 个值，于是各国纷纷物尽其用，将一个字节中 ASCII 并没有用到的 128 到 255 对应为自己国家所需要用到字符。这些五花八门的对应规则便是后来的代码页（code page），同样的值可以在不同的代码页中表示不同的字符。

到目前为止，char 类型还算是名副其实的字符类型。然而，东亚文化圈广泛使用的汉字成千上万，少说也需要上千个码位，一个字节所能提供的这区区 256 个码位实在是杯水车薪。

计算机科学里的任何问题都可以通过增加一个中间层来解决。

既然码位不得不超过 255，一个字节放不下，那么将以前的「码位→字节」变成「码位→编码→字节序列」如何？

举个栗子：Unicode 字符集中，字符「汉」的码位是 27721（十六进制 6C49），一个字节显然容不下，我们可以通过 UTF-8 编码将其变成字节序列。

1. 通过字符集找到对应码位：汉→ U+6C49；
2. 根据 UTF-8 编码规则，介于 U+0800 和 U+FFFF 之间的码位需要按照 1110xxxx 10xxxxxx 10xxxxxx 的形式编码为三个字节；
3. 6C49 的二进制形式是 0110 1100 0100 1001，代入上面的模板得到 11100110 10110001 10001001；
4. 得到最终的字节序列 E6 B1 89。

看上去不错，但这样一来，char 这个「字符」类型就有点名不副实了：一个 char 可能只是一个字符的一部分，只有两个或者更多的 char 拼起来才能够表示一个字符。更为麻烦的是，相关的标准库也变得不再可靠了：类似 strlen() 这种 too simple, sometimes naive 的方法顿时从返回字符串的字符数降级成了返回字符串的字节数。

printf("%zu\n", strlen("\xE6\xB1\x89"));  // 输出 3；但实际上只有一个字：汉

多字节字符串

为了解决 strlen() 的这种尴尬，C 语言中引入了「多字节字符串」（multibyte string）的概念，一个字符可以对应多个字节；而原先的字符串则对应称为「字节字符串」（byte string），一个字符只能对应一个字节。

char const *multibyteString = "Hello 世界";  // 和普通字符串没什么区别

多字节字符串依旧是 char *，所以这两者的区别其实只是抽象概念上的，何况严格来说，字节字符串也是一种特殊的多字节字符串。

不同的编码每个字符占用的字节数可能不同，即便是同一种编码，不同的字符也可能占用不同的字节数。所以多字节字符串面临的主要问题便是「下一个字符到底占几个字节」。C 语言引入了 mblen() 函数来回答这个问题：

int mblen(char const *s, size_t n);

其中 s 是一个多字节字符串，而 n 表示至多检查多少个字节；这个函数会根据当前区域设置（Locale）的 LC_CTYPE 分类中所指定的编码来解析这个多字节字符串，返回该字符串的字一个字符占几个字节。

char const *multibyte= "\xE6\xB1\x89"; // 「汉」的 UTF-8 编码
printf("%d\n", mblen(multibyte , 5));  // 输出 -1；因为默认区域设置为 C，无法识别这样的序列。
setlocale(LC_CTYPE, "en_US.UTF-8");    // 非 Windows 平台用，Windows 平台不支持 UTF-8 的区域设置 
printf("%d\n", mblen(multibyte, 5));   // 输出 3；因为当前区域设置为 UTF-8 编码。

宽字符 wchar_t

多字节字符串的引入终于算是「一定程度上解决了问题」，但这种做法实在繁琐。于是，C 语言同时引入了宽字符类型 wchar_t 和配套支持库 wchar.h，试图一劳永逸地解决这个问题。

wchar_t const *wideString = L"Hello World";  // 使用前缀 L

与 char 的一个字节不同，wchar_t 类型本身可以占多个字节，保证永远与字符一一对应，省下了编码的步骤。如此就可以通过 wchar.h 中提供的 wcslen() 函数正确计算 wchar_t * 字符串中的字符数了。

多字节字符串和宽字符串的转换

与 mblen() 类似，C 语言提供了两组共四个函数，根据当前的区域设置进行多字节字符（串）和宽字符（串）的转换。

• wctomb() 将宽字符转换为多字节字符
• mbtowc() 将多字节字符转换为宽字符
• wcstombs() 将宽字符串转换为多字节字符串
• mbstowcs() 将多字节字符串转换为宽字符串

误区

看到这里，你是否想过这个能够保证与字符一一对应的 wchar_t 类型到底需要占几个字节呢？没错，不一定占多少，但总之至少一个字节就对了！

事实上，关于 wchar_t 的准确要求是：能够容纳下所支持的区域设置中，最大的扩展字符集中的每一个码位。

an integer type whose range of values can represent distinct codes for all members of the largest extended character set specified among the supported locales.

也就是说，如果有一个只支持 ASCII 字符集的奇葩的 C 语言实现存在，那么在这个实现下，wchar_t 完全可以只占 8 位。

如此，我们经常听到的「宽字符和 Unicode 有关」的说法也就不攻自破了。

C11 中引入的定长字符类型

时过境迁，转眼到了 2011 年。正如 C99 中在 stdint.h 中加入了 uint32_t 之类的定长整数类型一样，C11 也引入了两种定长字符类型以满足 Unicode 的需要：

• char16_t 占 16 位，2 字节，可以保存 UTF-16 字符。
• char32_t 占 32 位，4 字节，可以保存 UTF-32 字符。

同时，继 string.h、wchar.h 后，又进入了 uchar.h 作为这两种字符类型的支持库。

char16_t *utf16String = u"Hello UTF-16";  // 使用前缀 u
char32_t *utf32String = U"Hello UTF-32";  // 使用前缀 U

C++ 中的字符串

C++ 极尽所能兼容 C 语言，陆续支持了和 C 语言相同的那些 char、wchar_t、char16_t 和 char32_t 类型，这里就不再重复了。

至于 std::string，用 C++ 不可能没听说过，它封装了常用的字符串操作。但你是否知道 std::wstring 的存在呢？

如果有心，你会发现 std::string 实际上是对 std::basic_string<T> 模板的特化，形式类似于：

typedef std::basic_string<char>    std::string;
typedef std::basic_string<wchar_t> std::wstring;

至于 C++11 中，由于 char16_t 和 char32_t 的引入，也对应增加了 std::u16string 和 std::u32string 的特化版本。

std::basic_string::data() 在 C++11 以来的改变

std::basic_string<T> 其实只是对 T 字符数组的封装，如果需要使用 C 风格的字符串 T *，可以通过 c_str() 方法获取。

而如果说 c_str() 方法表示「获取该类对应的 C 字符串表示」的语义，那么 data() 方法则表示「获取该类实际保存的数据」的语义。

在 C++11 之前，通过 data() 方法获取的 T * 并不保证 NUL 结尾，即仅保证 [data(), data() + size()) 有效。而自 C++11 起，data() 变为保证 NUL 结尾，与 c_str() 的行为完全相同。

从 C++17 开始，我们还可以 data() 方法获取可修改的缓冲。

Windows API 中的字符串类型

不得不说，Windows 的各种大写的自定义类型实在丑陋得令人发指。经常不由得让人发出「好好起名字会死么？」的感叹。

#define CHAR    char
#define LPSTR   char *
#define LPCSTR  char const *

#define WCHAR   wchar_t
#define LPWSTR  wchar_t *
#define LPCWSTR wchar_t const *

当然，微软如此做法自然有其历史原因，我对所谓的「向前兼容」表示非常无奈。不过话说回来，除了 Windows API 如此大张旗鼓地使用 wchar_t，其余地方真不怎么能见到宽字符的身影。现代 Windows 内部使用 UTF-16，所以 wchar_t 能够保证是 16 位的。

Windows API 中所有与字符串相关的函数、数据结构等，都存在 ANSI 和 Unicode 两个版本，可以通过宏 UNICODE 来切换。比如一个普通的 MessageBox() 函数，实际定义是这样的：

int MessageBoxW(HWND hWnd, LPCWSTR text, LPCWSTR caption, UINT type);  // 宽字符串版本
int MessageBoxA(HWND hWnd, LPCSTR  text, LPCSTR  caption, UINT type);  // 多字节字符串版本

#ifdef UNICODE
#define MessageBox MessageBoxW
#else
#define MessageBox MessageBoxA
#endif

字符类型也是类似，使用 TCHAR 作为一个通用的字符名字。字符常量则使用 TEXT() 宏来定义。

#ifdef UNICODE
#define TCHAR    WCHAR
#define TEXT(s)  L ## s
#else
#define TCHAR    CHAR
#define TEXT(s)  s
#endif

如果你用的是 Visual C++，这个 UNICODE 宏通常并不需要手动设置，而是作为工程属性的一员出现的。

p.s. 不要被这个宏的名字骗了，还记得之前我们说过的 wchar_t 和 Unicode 一点关系都没有吗？可以这么理解：wchar_t 只在 Windows API 中表示 UTF-16 数据。

宽窄字符串的转换

Windows 平台也可以用之前提到的四个函数转换 char 字符串和 wchar_t 字符串。但 Windows 本身提供的 API 似乎更有效率：

• MultiByteToWideChar() 多字节字符串转换为宽字符串
• WideCharToMultiByte() 宽字符串转换为多字节字符串

再次吐槽 M$ 这蛋疼的命名，命名是转换字符串，起名字起得跟转换单个字符一样。

BSTR

BSTR 可以解释为 Basic String 或者 Binary String，是 Windows 下用于 COM、自动化的字符串类型。定义为：

typedef OLECHAR *BSTR;

OLECHAR 是 Windows 的历史遗留，类似于根据宏 OLE2ANSI 转换的 TCHAR，但 OLE2ANSI 是 16 位时代的产物，于是 Win32 环境下，OLECHAR 永远是 WCHAR，也就是 wchar_t。

尽管如此，BSTR 并不能等同于 OLECHAR *，因为它们的内存布局不同：BSTR 在它自身前拥有一个四个字节的前缀、以双 NUL 结尾。其中，前缀用于描述字符串内容所占的字节数，它本身所指向的是字符串内容而非长度。

-4          0           2           4           6           8          10        
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|     6     |     H     |     i     |     !     |    NUL    |    NUL    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
            ↑
            bString

这一点，从用于创建 BSTR 的接口 SysAllocString() 便可以看出：

BSTR SysAllocString(OLECHAR const *psz);

倘若 BSTR 与 OLECHAR * 相同，那么岂不变成了鸡生蛋、蛋生鸡的问题？

虎头蛇尾

呃……前面讲 C 语言字符串的时候似乎还是觉得挺有说头，足足规划了一个星期之久，但后面似乎越来越不知道该讲什么，留待日后积累到新的东西再完善吧～

以上。

众所周知，char 类型是独立于 unsigned char 和 signed char 之外的一种实现相关类型，这着实带来了不少麻烦。

std::string a = "Hello";
std::string b = "世界";  // UTF-8 或者 GBK 皆可

那么请问，a[0] < b[0] 是什么结果？OK，那么 a < b 呢？

当然，貌似在开篇头一句就已经被我剧透的情况下作出错误的回答还是蛮困难的。没错，无论是 GBK 还是 UTF-8 存储，答案都应该是：

• a[0] < b[0] 与实现相关。在我的 Windows 7 32-bit 和 Arch Linux 64-bit 上，都是 false
• a < b 永远为 true

前者很好理解，因为实质是两个 char 在比较，所以谁大谁小还得看 char 到底是无符号的还是有符号的。而后者为什么肯定是 true 呢？

尽管 std::string 是 std::basic_string 在字符类型为 char 时的特化，但 C++ 标准中明确规定：

The two-argument members eq and lt shall be defined identically to the built-in operators == and < for type unsigned char.

也算是 C++ 造福人类的某种方式吧。

以上。

上一次看 cocos2d-x 是去年的事情了，下了个 SDK 而后按照官方的那个 pew-pew-pew 教程接二连三捣鼓了几下，之后几乎就没怎么去碰了。最近再看感觉连当时自己写的代码都快不认识了，果然还是需要记下笔记 = =

获取 SDK

前往 cocos2d-x 官网下载稳定版打包，或者去官方 GitHub 仓库 git clone 一份（注意看清分支哟）。

个人这回是下载了最新稳定版本，目前是 2.1.4。

创建工程

Cocos2d-x 由若干部分组成，有些采用静态链接、有些则是动态链接、更有些是直接源代码分发的；加上工程本身的跨平台属性，需要针对不同平台写初始化代码；总而言之，从零开始手写一个空工程是相当繁琐的。

所以老版本的策略是：为不同平台下的开发工具提供模板、脚本之类的东西以便获得每次的初始空工程。比如它会为 Visual Studio 安装一个 cocos2d-x 程序模板，这样就可以直接在新建对话框里选择新建一个 Visual C++ 的空 cocos2d-x 工程了。

当然，从 2.1.4 版本开始，官方就不再为 VS 提供模板了，逐步在各平台采用统一的 Python 脚本创建跨平台工程。（吐槽：虽然不提供模板了，但是原先用来安装模板的 install-templates-msvc.bat 文件居然还在，虽然一运行就报错的说……）

这个创建脚本使用 Python 2.X，同时它还有一个 Bug：使用当前目录而不是脚本文件所在目录查找模板文件（GitHub 上的 develop 版已经修复）。所以，要创建工程，我们需要先从命令行进入 tools/project-creator 目录，然后再使用

create_project.py -project <工程名称> -package <Java 包名> -language <语言>

就会在 projects 目录下创建相应的工程。这一点在直接运行 create_project.py 时会给出提示。（3.0 版本将在 cocos2d-x 根目录提供 create-multi-platform-projects.py 文件为你间接调用 tools/project-creator/create_project.py）那么作为一个示例，我们可以输入：

create_project.py -project Whatever -package com.timothyqiu.Whatever -language cpp

咳咳，如果你对为什么语言是 C++ 也要输入「Java 包名」感到困惑，那么看一眼生成后的工程目录结构就明白了：

Whatever -+- Classes
          |- Resources
          |- proj.android
          |- proj.blackberry
          |- proj.ios
          |- proj.linux
          |- proj.mac
          |- proj.marmalade
          `- proj.win32

结构非常精巧：平台无关的（自己写的逻辑之类的）代码都在 Classes 目录下；程序用到的资源都在 Resources 目录下；其余的平台相关（预置的初始化之类的）代码及工程文件都在各自的目录下。

所以，既然有 Android 工程在，那么创建时显然是需要包名的。

渲染树

如果你熟悉 3D 也许你也熟悉「渲染树」的概念：加入渲染树的节点才能够被渲染，而节点的父子关系也对其位移、缩放、旋转有相应影响。渲染一帧图像的过程就是遍历整棵渲染树、依次绘制各个节点的过程。

cocos2d-x 中的节点，以 CCNode 表示，它除了作为一棵渲染树的节点外，还提供了定时回调以及执行 CCAction 动作的功能。当然， CCNode 还封装了一些类似位置、缩放、旋转的基本属性，其中锚点（Anchor Point）是非常重要的属性：节点的位置和节点左上角、右下角的位置是什么关系？缩放以哪个点为定点？旋转以哪个点为中心？这些问题的答案就是锚点。

cocos2d-x 中对象的属性使用 Getter/Setter 封装，均为 setPropertyName(value) 和 getPropertyName()、isPropertyName() 的形式。一些 CCNode 常用属性如下：

• 位置（Position）默认为 (0, 0)，是一个 CCPoint 类型的值。
• 旋转（Rotation）默认为 0，顺时针以角度计。
• 缩放（Scale）默认为 1.0f。
• 尺寸（ContentSize）默认为 (0, 0)，是一个 CCSize 类型的值。
• 可见（Visible）默认为 true。不可见和不存在是两码事。
• 锚点（AnchorPoint）默认为 (0, 0)。每个分量都是一个浮点数，0.0f 表示左上，1.0f 表示右下（所以 0.5f 表示中心点）。取值也可以不在 0 和 1 的范围内，表示锚点位置在节点范围外。

另外还有 Tag、UserData、UserObject 三人组，类型分别是 int、void * 和 CCObject，都是用户为节点自定义的数据，CCNode 只是把它存起来以供你日后获取，不作它用。

CCNode 常见的一些子类包括：

• CCScene 场景，一般作为渲染树的根节点存在
• CCLayer 层，一般作为精灵的容器存在，能够接受外部输入（触摸事件、加速计等）
• CCSprite 精灵，图像节点
• CCMenu 抽象菜单，可以添加 CCMenuItem 的 UI 元素。本身是从 CCLayer 派生的

出于拯救大众于水火的目的，以上子类的锚点都被默认设成了 (0.5, 0.5)。

p.s. cocos2d-x 中的绝大多数类均以 CC 作为前缀。但这样的做法明显是与它们所在的 cocos2d 这个 namespace 重复的，所幸在将来的 3.X 新版本中这些重复的前缀都会被删掉。

无规矩不成方圆

cocos2d-x 基于 OpenGL，故使用右手坐标系：从左到右、从下到上为坐标轴正方向。

前面说过的 CCPoint 类型，可以用来表示坐标点，也可以用来表示向量；而 CCSize 类型类似，用来表示尺寸；另外还有一个 CCRect 是 CCPoint 和 CCSize 的组合，表示矩形区域的左上角和尺寸。

因为 CCPoint 和 CCSize 实质都是两个 float 的组合，所以其构造函数也都需要两个 float。介于每次传入不同类型变量的都显式去 static_cast<float> 过于手残，cocos2d-x 给出了三个对应的宏来帮你写转型：CCPointMake(x, y)、CCSizeMake(w, h) 和 CCRectMake(x, y, w, h)。当然，CCPoint 太常用了，以至于它还有一个更省击键数的宏 ccp(x, y)。

前面还说过旋转属性，它是一个角度值。cocos2d-x 提供了 CC_DEGREES_TO_RADIANS(deg) 和 CC_RADIANS_TO_DEGREES(rad) 宏进行弧度、角度的换算。

内存管理

cocos2d-x 使用了来自 cocos2d-iphone 的 Objective-C 风格，这不仅体现在代码风格上，还体现在内存管理风格上。

Objective-C 的内存管理使用的是（手动）引用计数技术。简而言之，就是对象默认存在 1 个引用、用 retain() 可以增加一个引用、用 release() 可以减少一个引用。一旦引用减少到 0，对象自动释放。

聪明的你一定想到了不少实现方法。不过由于目前版本中所有对象都只是裸指针（例如 CCDirecter *director 的本质是一个指针而非对象），所以，似乎在这一前提下实现引用计数的唯一方法就是：所有对象都继承自同一根类，由这个根类负责进行引用计数工作。当然如此一来，所有对象都应该创建在堆上。

顺带一提，cocos2d-x 当前版本并没有使用智能指针，一是因为 cocos2d-iphone 就是如此，二是因为 cocos2d-x 项目启动时 C++11 仍未定稿，三是因为当时各手机平台上支持情况不一样。不过时过境迁，在 2013 都过去了一半的现在，官方已经决定在 3.0 新版本里引入 C++11 的智能指针。

根对象

cocos2d-x 用来提供引用计数功能的根类就是 CCObject。主打这四个函数：

• CCObject::CCObject()
• CCObject::retain()
• CCObject::release()
• CCObject::autorelease()

前三个好说，分别是将当前对象的引用计数置一、增一、减一。那么最后一个 autorelease() 是干啥的？

借用 Objective-C 中的解释：release() 是引用计数立即减一，而 autorelease() 则是在不久的将来减一（至少在当前函数之后）。

在 cocos2d-x 的实现中，使用了名叫 CCAutoReleasePool 的「自动释放池」对象。它会在自身被释放（析构）时调用其所持有的所有对象的 release() 方法。CCObject::autorelease() 所做的正是将自己加入自动释放池中。

cocos2d-x 会在每一帧的开始创建一个 CCAutoReleasePool，并在该帧结束时释放它。所以，所有被调用过 autorelease() 的 CCObject 都有机会在当前帧结束后自动释放。（之所以是「有机会」，因为即使调用 release() 同样也只是有机会释放，是否真正释放由引用计数决定。）

所以，大致小结一下就是：

• 每一次 new 或者 retain() 都应该对应存在一次 autorelease() 或者 release()
• autorelease() 是有代价的，所以应该尽量使用 release()

创建和销毁

cocos2d-x 中没有使用异常，所以对象的创建使用了两步构造法（Two-phase Construction）。所谓两步构造法，就是构造函数只用来为变量赋初值而不执行逻辑相关代码，所有初始化用的功能代码另写一个初始化函数。（构造函数没有返回值，所以只能用异常与外界沟通。）

CCSprite *sprite = new CCSprite();       // 创建对象
sprite->initWithFile("background.png");  // 初始化对象

上面这两行就是两步构造法的一个实例。介于这么写相当的繁琐，cocos2d-x 为每一个 initXXX() 都提供一个相应的工厂方法 createXXX()：

CCSprite *sprite = CCSprite::create("background.png");

其实现很简单：

CCSprite *pobSprite = new CCSprite();
if (pobSprite && pobSprite->initWithFile(pszFileName)) {
    pobSprite->autorelease();
    return pobSprite;
}
CC_SAFE_DELETE(pobSprite);
return NULL;

注意到其中的 autorelease() 了吗？这意味着，如果只是 create() 而没有做其它任何操作，那么这个对象会在本帧结束时释放；但如果在 create() 后调用了 sprite->retain()，那么这个对象就不会自动释放（如果是 this->addChild(sprite) 则同理，因为 addChild() 会间接调用 retain()）。

需要注意的是，这种创建方式也导致父类无法自动初始化，必须在子类的 initXXX() 方法里手动去调用直接父类的 initXXX() 方法。于是（如果手写），一般的初始化都类似于：

bool HelloWorldLayer::init()
{
    bool success = false;
    do {
        CC_BREAK_IF(!CCLayer::init());
        // actual init code here, break if failed
        success = true;
    } while (0);
    // clean up if nescesary
    return success;
}

容器

因为 cocos2d-x 的这种「特殊」内存管理方式，对 retain()、release() 一无所知的 STL 容器或许并不适合你，于是便有了 CCArray、CCSet、CCDirectory。（在 STL 容器中直接存放裸指针，可能由于野指针带来各种麻烦。当然，如果考虑使用智能指针的话，存入对应 std::shared_ptr 即可保证容器生命周期内所含对象有效；而 cocos2d-x 在未来版本中全面引入智能指针代替 Objective-C 风格的内存管理后，单存入 std::weak_ptr 就可以检测到野指针了。）

cocos2d-x 所提供的这些容器所存放的都是 CCObject 对象（其实是指针，但鉴于正确的使用方法只可能是指针，所以方便起见以后就不强调是指针了）。在对象进入容器时，容器自动调用一次 retain() 取得其引用；在对象移出容器或是容器本身被销毁时，容器自动为对象调用一次 release() 放弃引用。

这样就保证了所有在这些容器中的对象都是有效的对象。（还记得 CCAutoReleasePool 吗？它就是用 CCArray 实现的。）

对于容器，除却添加删除，常用的还有遍历。与 STL 提供迭代器不同，CCArray 和 CCDirectory 都是用 For Each 宏来遍历的。（CCSet 和 STL 相同。）

CCObject *element = nullptr;
CCARRAY_FOREACH(arrayOfSprites, element) {
    auto sprite = dynamic_cast<CCSprite *>(element);
    // ...
}

导演

CCDirector 类就是导演类，（总）导演每部戏只有一个，所以它是个单件类。cocos2d-x 中所有单件类都通过类似 CCName::sharedName() 的方式获得 CCName * 单件对象。这种（命名）习惯是从 cocos2d-iphone 里带来的，在 3.X 中，将会变成 CCName::getInstance() 这种更方便的方式。

导演的主打功能是场景调度和游戏流程控制。

• runWithScene() 开始运行，设置初始场景
• replaceScene() 切换场景，不保留旧场景
• pushScene()、popScene() 常见的场景栈式管理
• pause() 暂停当前场景（仍有会绘制场景，但是不会执行逻辑）
• resume() 恢复当前场景
• end() 结束运行

细枝末节

在 SDK 为我们提供的空工程中，除了上面提到的这些「大头」，还有一些零碎的细枝末节。

入口

事实上，每一个 proj.* 目录下都有自己平台的初始化代码，也就是各自类似于 main() 的东东。

而在 Classes 目录下，平台无关代码中，程序的入口便是 AppDelegate 类。没错，这个类（依旧）源自 cocos2d-iphone，确切的说是 iOS，个人理解，这是一个用来接收程序 UI 状态消息的类。

程序通过其中仅有的三个顾名思义的方法 applicationDidFinishLaunching() applicationDidEnterBackground() applicationWillEnterForeground() 来感知自身的状态，以作出反应。比如 Did finish launching 时初始化引擎；Did enter background 时暂停背景音乐、暂存状态；Will enter foreground 时取出状态、恢复背景音乐等等。

现有的「空工程」中，applicationDidFinishLaunching() 里的核心其实就是这两句：

CCScene *pScene = HelloWorld::scene();
pDirector->runWithScene(pScene);

它搭建了 Classes 目录下 AppDelegate 和 HelloWorld 这两个类的桥梁：将场景创建出来后交给导演，然后导演就自顾自干活去了。

选择器

在 HelloWorld.cpp 中，我们可以看到这样的语句：

CCMenuItemImage *pCloseItem = CCMenuItemImage::create(
    "CloseNormal.png", "CloseSelected.png",
    this, menu_selector(HelloWorld::menuCloseCallback)
);

这个 menu_selector 好神奇，究竟是什么？

好吧，这货（没错，还）是从 cocos2d-iphone 来的，我们来看实际代码（2.1.4 版本的 C 风格转换看着不爽，这里使用 C++ 风格类型转换稍作修改）：

typedef void (CCObject::*SEL_MenuHandler)(CCObject*);
#define menu_selector(_SELECTOR) static_cast<cocos2d::SEL_MenuHandler>(&_SELECTOR)

你看，没什么大不了的，各种 selector 都只是「成员函数指针 + 强制类型转换」而已，它和它的前一个参数（CCObject *）共同指定了一个回调。（回想一下，你还记得 C++ 里该如何定义、初始化、使用成员函数指针吗？）

当然，在不久的将来，3.X 版本会使用更灵活的 std::function 和 std::bind 来代替这种「selector」。

以上。