第十二篇：SOUI的utilities模块为什么要用DLL编译？

SOUI相对于DuiEngine一个重要的变化就是很多模块变成了一个单独的DLL。

然后很多情况下用户可能希望整个产品就是一个EXE，原来DuiEngine提供了LIB编译模式，此时链接LIB模式的DuiEngine就行了。

但是SOUI默认至少Utilities那个模块是不提供LIB编译模式的。

utilities之所以默认只提供DLL编译是因为SString类是由utilities实现的。

字符串是编译中碰到的最最见的基本对象之一。在运行库（CRT）动态编译（MD，MDd）时这不是问题，因为所有模块的内存分配都是在一个相同的运行库（CRT）上，这时在不同模块之间传递对象相对简单。如果项目采用运行库静态编译（MT or MTd)，在不同模块之间传递字符串对象是非常困难的，因为一不小心就会发生在A模块中分配的字符串对象被B模块释放。

utilities采用DLL编译就是为了解决这个字符串对象的跨模块传递。

采用运行库动态编译的情况就不说了，这里主要介绍采用静态库编译的CRT的情况。

SOUI中使用的字符串对象采用了一点技巧：每一个String对象中只有一个指针成员变量：

    template <class tchar, class tchar_traits>
    class TStringT
    {
    public:
        typedef tchar    _tchar;
        typedef const _tchar * pctstr;

    protected:
        tchar* m_pszData;   // pointer to ref counted string data
    };

虽然TStringT是一个模板类，在SOUI中采用类导出的方式将该模板的两个特化类导出：

#ifdef UTILITIES_EXPORTS
#    define EXPIMP_TEMPLATE
#else
#    define EXPIMP_TEMPLATE extern
#endif

     #pragma warning (disable : 4231)

    EXPIMP_TEMPLATE template class UTILITIES_API  TStringT<char, char_traits>;
    EXPIMP_TEMPLATE template class UTILITIES_API  TStringT<wchar_t, wchar_traits>;

通过将string类导出，保证string的所有运行代码都是在utilities这个模块内部，这也就保证了string对象的唯一成员变量：

tchar* m_pszData；

的内存分配及释放固定在utilities这个模块里。

通过这样处理，无论用户定义string是在哪一个模块，真正的内存管理还是在utilities里，从而使得string对象可以方便的在不同模块之间传递。

比较一下std::string就可以发现，如果使用std::string在不同模块之间传递对象将是非常危险的，因为std::string是模板类，它的代码将会被编译到不同的模块中，也就是说在不同的模块中调用std::string的成员函数执行的代码是不一样的，这样在A模块中声明的string传递到B模块再被B模块释放程序就崩溃了。

这就是为什么utilities模块默认只提供DLL编译的原因。

知道了原因就好办了。

对于那些希望整个项目就是一个EXE的情况，直接修改utilities模块的编译类型为LIB就行了，因为这种情况下根本不存在跨模块对象传递的问题。