今天心情好，所以再来批评一下 Symbian。其实这些问题可能 Nokia 有更大的责任，不过既然 Symbian 是基础结构么，说它也不为过。
1、纵观所有版本的 SDK，没有一个头文件里有可以标识 SDK 版本（或者操作系统版本，或者 UI 平台版本）的宏定义。
这 种短视的行径长期没有得到改观。如果你想写一份在不同的 SDK 中都能正常编译的代码，简直就是困难重重。你一定想用预定义宏来区分，可是你一定会被显示撞的头破血流。一个名叫 e32ver.h 的头文件看起来好象是做这个用途的，可是打开一看你就会傻眼，里面不是宏定义，而是 const int。我想写这个头文件的工程师的大脑一定是被所谓的“纯 C++”或者“纯 OO”之类的茅草塞满了，看到宏就会下意识地写为 const int，完全不知道这些数值应该有什么用以及会怎么样被别人使用。
Nokia S60 三版的 SDK 里，include\variant 目录里有个文件，针对相关的平台定义了一系列的东西，但是，这个文件的文件名里竟然有版本号信息！这就意味着你需要分清楚 SDK 版本之后才能包含到正确的文件上，而不能达到用它来帮助你分清楚 SDK 版本的目的！
2、mmp 文件中不支持自定义库文件路径。
你 没有任何办法在 mmp 文件中指定所依赖的库文件的搜索路径，尽管编译环境调用到的链接器最终无一例外都支持这一特性。LIBRARY 关键字是不支持绝对路径的，而相对路径的起点就是 SDK 的库文件所在路径。这就意味着，如果你有自己的库需要链接进来，那你就只能很愚蠢地把它们复制到 SDK 的库文件所在路径下，抱歉，也没有便利的编译后清理设施，日积月累，你的 SDK 会成为一个巨大的垃圾场。
3、愚蠢的 _LIT 宏
你想这样使用 _LIT 吗：
#define STR_HELLO_WORLD “Hello, world!”
_LIT(KStrHelloWorld, STR_HELLO_WORLD);
很对不住，编译器会罢工，告诉你第二参数有问题。老汉一时手痒，所以写了下面的解决方案（一个 litfix.h 头文件）：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
#ifndef __LITFIX_H__ #define __LITFIX_H__ #ifdef _LIT #undef _LIT #endif #if defined(_UNICODE) #define __TSTR(x) L ## x #else #define __TSTR(x) x #endif // // NOTE: // Now, you can use _LIT macro as following: // // #define STR_HELLO_WORLD "Hello, world!" // _LIT(KStrHelloWorld, STR_HELLO_WORLD); // // You can NOT use anothor string macro as the second parameter // in the original _LIT. // // #define _L(a) (TPtrC((const TText *)__TSTR(a)) // #define _S(a) ((const TText *)__TSTR(a)) #define _LIT(name, s) \ static const TLitC<sizeof(__TSTR(s)) / sizeof(TText)> name = \ { sizeof(__TSTR(s)) / sizeof(TText) - 1, __TSTR(s) } #endif // __LITFIX_H__ |
使 用的时候在 cpp 中把它包含到其他所有的头文件之后就可以了。可能是由于上面已经提到过的原因，Symbian 的工程师对于宏的使用，只能算是入门级的水平。如果谁要是不相信，还可以去看看可变参数相关的那一干宏（VA_XXX）的实现，保管你不止大跌眼镜，而是 大跌眼睛……
不好意思，话题有大有小，精粗并杂，日后再整理。
未完待续。下面是不完全/不确定的目录：
4、无处不在的白痴 UID3（看它是如何影响复用的）
5、过度 OO 设计（去看看系统的消息体系吧）
6、复杂的安全模型（哦，是我见过的最安全的设计了……）
7、糟糕的模拟器（你见过它的几种死法？）
8、弱智的桌面扩展体系（Desktop/Idle/Home/Tel，随便你怎么叫他）
9、WSD 和 Cleanup Stack（已经被无数人诟病，这里提一下权当充数）