发布网友 发布时间:2022-04-24 04:37
共1个回答
热心网友 时间:2023-10-28 19:08
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模块释放程序就崩溃了。
热心网友 时间:2023-10-28 19:08
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模块释放程序就崩溃了。
热心网友 时间:2023-10-28 19:08
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模块释放程序就崩溃了。
热心网友 时间:2023-10-28 19:08
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模块释放程序就崩溃了。
热心网友 时间:2023-10-28 19:08
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模块释放程序就崩溃了。