学设计的素材网站,国外购物平台有哪些,完成一个个人主页网站的制作,wordpress水平菜单写在前面
序列化是一个转储-恢复的操作过程#xff0c;即支持将一个对象转储到临时缓冲或者永久文件中和恢复临时缓冲或者永久文件中的内容到一个对象中等操作#xff0c;其目的是可以在不同的应用程序之间共享和传输数据#xff0c;以达到跨应用程序、跨语言和跨平台的解耦…写在前面
序列化是一个转储-恢复的操作过程即支持将一个对象转储到临时缓冲或者永久文件中和恢复临时缓冲或者永久文件中的内容到一个对象中等操作其目的是可以在不同的应用程序之间共享和传输数据以达到跨应用程序、跨语言和跨平台的解耦以及当应用程序在客户现场发生异常或者崩溃时可以即时保存数据结构各内容的值到文件中并在发回给开发者时再恢复数据结构各内容的值以协助分析和定位原因。
泛型编程是一个对具有相同功能的不同类型的抽象实现过程比如STL的源码实现其支持在编译期由编译器自动推导具体类型并生成实现代码同时依据具体类型的特定性质或者优化需要支持使用特化或者偏特化及模板元编程等特性进行具体实现。
Hello World
#include iostream
int main(int argc, char* argv[])
{std::cout Hello World! std::endl;return 0;
}
泛型编程其实就在我们身边我们经常使用的std和stl命名空间中的函数和类很多都是泛型编程实现的如上述代码中的std::cout即是模板类std::basic_ostream的一种特化
namespace std
{typedef basic_ostreamchar ostream;
}
从C的标准输入输出开始
除了上述提到的std::cout和std::basic_ostream外C还提供了各种形式的输入输出模板类如std::basic_istream std::basic_ifstreamstd::basic_ofstream std::basic_istringstreamstd::basic_ostringstream等等其主要实现了内建类型built-in的输入输出接口比如对于Hello World可直接使用于字符串然而对于自定义类型的输入输出则需要重载实现操作符和如对于下面的自定义类
class MyClip
{bool mValid;int mIn;int mOut;std::string mFilePath;
};
如使用下面的方式则会出现一连串的编译错误
MyClip clip;
std::cout clip;
错误内容大致都是一些clip不支持操作符并在尝试将clip转为cout支持的一系列的内建类型如void*和int等等类型时转换操作不支持等信息。
为了解决编译错误我们则需要将类MyClip支持输入输出操作符和类似实现代码如下
inline std::istream operator(std::istream st, MyClip clip)
{st clip.mValid;st clip.mIn clip.mOut;st clip.mFilePath;return st;
}
inline std::ostream operator(std::ostream st, MyClip const clip)
{st clip.mValid ;st clip.mIn clip.mOut ;st clip.mFilePath ;return st;
}
为了能正常访问类对象的私有成员变量我们还需要在自定义类型里面增加序列化和反序列化的友元函数回忆一下这里为何必须使用友元函数而不能直接重载操作符和如
friend std::istream operator(std::istream st, MyClip clip);
friend std::ostream operator(std::ostream st, MyClip const clip);
这种序列化的实现方法是非常直观而且容易理解的但缺陷是对于大型的项目开发中由于自定义类型的数量较多可能达到成千上万个甚至更多时对于每个类型我们则需要实现2个函数一个是序列化转储数据另一个则是反序列化恢复数据不仅仅增加了开发实现的代码数量如果后期一旦对部分类的成员变量有所修改则需要同时修改这2个函数。
同时考虑到更复杂的自定义类型比如含有继承关系和自定义类型的成员变量
class MyVideo : public MyClip
{std::listMyFilter mFilters;
};
上述代码需要转储-恢复类MyVideo的对象内容时事情会变得更复杂些因为还需要转储-恢复基类同时成员变量使用了STL模板容器list与自定义类MyFilter的结合这种情况也需要自己去定义转储-恢复的实现方式。
针对以上疑问有没有一种方法能减少我们代码修改的工作量同时又易于理解和维护呢
Boost序列化库
对于使用C标准输入输出的方法遇到的问题好在Boost提供了一种良好的解决方式则是将所有类型的转储-恢复操作抽象到一个函数中易于理解如对于上述类型只需要将上述的2个友元函数替换为下面的一个友元函数
templatetypename Archive friend void serialize(Archive, MyClip, unsigned int const);
友元函数的实现类似下面的样子
templatetypename Avoid serialize(A ar, MyClip clip, unsigned int const ver)
{ar BOOST_SERIALIZATION_NVP(clip.mValid);ar BOOST_SERIALIZATION_NVP(clip.mIn);ar BOOST_SERIALIZATION_NVP(clip.mOut);ar BOOST_SERIALIZATION_NVP(clip.mFilePath);
}
其中BOOST_SERIALIZATION_NVP是Boost内部定义的一个宏其主要作用是对各个变量进行打包。
转储-恢复的使用则直接作用于操作符和比如
// store
MyClip clip;
······
std::ostringstream ostr;
boost::archive::text_oarchive oa(ostr);
oa clip;// load
std::istringstream istr(ostr.str());
boost::archive::text_iarchive ia(istr);
ia clip;
这里使用的std::istringstream和std::ostringstream即是分别从字符串流中恢复数据以及将类对象的数据转储到字符串流中。
对于类MyFilter和MyVideo则使用相同的方式即分别增加一个友元模板函数serialize的实现即可至于std::list模板类boost已经帮我们实现了。
这时我们发现对于每一个定义的类我们需要做的仅仅是在类内部声明一个友元模板函数同时类外部实现这个模板函数即可对于后期类的成员变量的修改如增加、删除或者重命名成员变量也仅仅是修改一个函数即可。
Boost序列化库已经足够完美了但故事并未结束
在用于端上开发时我们发现引用Boost序列化库遇到了几个挑战
端上的编译资料很少官方对端上编译的资料基本没有在切换不同的版本进行编译时经常会遇到各种奇怪的编译错误问题Boost在不同的C开发标准之间兼容性不够好尤其是使用libc标准进行编译链接时遇到的问题较多Boost增加了端上发行包的体积Boost每次序列化都会增加序列化库及版本号等私有头信息反序列化时再重新解析降低了部分场景下的使用性能
基于泛型编程的序列化实现方法
为了解决使用Boost遇到的这些问题我们觉得有必要重新实现序列化库以剥离对Boost的依赖同时能满足如下要求
由于现有工程大量使用了Boost序列化库因此兼容现有的代码以及开发者的习惯是首要目标尽量使得代码修改和重构的工作量最小兼容不同的C开发标准提供比Boost序列化库更高的性能降低端上发行包的体积
为了兼容现有使用Boost的代码以及保持当前开发者的习惯同时使用代码修改的重构的工作量最小我们应该保留模板函数serialize同时对于模板函数内部的实现为了提高效率也不需要对各成员变量重新打包即直接使用如下定义
#define BOOST_SERIALIZATION_NVP(value) value
对于转储-恢复的接口调用仍然延续目前的调用方式只是将输入输出类修改为
alivc::text_oarchive oa(ostr);
alivc::text_iarchive ia(istr);
好了到此为止序列化库对外的接口工作已经做好剩下的就是内部的事情应该如何重新设计和实现序列化库的内部框架才能满足要求呢
先来看一下当前的设计架构的处理流程图 比如对于转储类text_oarchive其支持的接口必须包括
explicit text_oarchive(std::ostream ost, unsigned int version 0);
template typename T text_oarchive operator(T v);
template typename T text_oarchive operator(T v);
开发者调用操作符函数时需要首先回调到相应类型的模板函数serialize中
template typename T
text_oarchive operator(T v)
{serialize(*this, v, mversion);return *this;
}
当开始对具体类型的各个成员进行操作时这时需要进行判断如果此成员变量的类型已经是内建类型则直接进行序列化如果是自定义类型则需要重新回调到对应类型的模板函数serialize中
template typename T
text_oarchive operator(T v)
{basic_saveT::invoke(*this, v, mversion);return *this;
}
上述代码中的basic_save::invoke则会在编译期完成模板类型推导并选择直接对内建类型进行转储还是重新回调到成员变量对应类型的serialize函数继续重复上述过程。
由于内建类型数量有限因此这里我们选择使模板类basic_save的默认行为为回调到相应类型的serialize函数中
template typename T, bool E false
struct basic_load_save
{template typename Astatic void invoke(A ar, T v, unsigned int version){serialize(ar, v, version);}
};template typename T
struct basic_save : public basic_load_saveT, std::is_enumT::value
{
};
这时会发现上述代码的模板参数多了一个参数E这里主要是需要对枚举类型进行特殊处理使用偏特化的实现如下
template typename T
struct basic_load_saveT, true
{template typename Astatic void invoke(A ar, T v, unsigned int version){int tmp v;ar tmp;v (T)tmp;}
};
到这里我们已经完成了重载操作符的默认行为即是不断进行回溯到相应的成员变量的类型中的模板函数serialize中但对于碰到内建模型时我们则需要让这个回溯过程停止比如对于int类型
template typename T
struct basic_pod_save
{template typename Astatic void invoke(A ar, T const v, unsigned int){ar.template save(v);}
};template
struct basic_saveint : public basic_pod_saveint
{
};
这里对于int类型则直接转储整数值到输出流中此时text_oarchive则还需要增加一个终极转储函数
template typename T
void save(T const v)
{most v ;
}
这里我们发现在save成员函数中我们已经将具体的成员变量的值输出到流中了。
对于其它的内建类型则使用相同的方式处理要以参考C std::basic_ostream的源码实现。
相应的对于恢复操作的text_iarchive的操作流程如下图 测试结果
我们对使用Boost以及重新实现的序列化库进行了对比测试其结果如下
代码修改的重构的工作非常小只需要删除Boost的相关头文件以及将boost相关命名空间替换为alivcBOOST_SERIALIZATION_FUNCTION以及BOOST_SERIALIZATION_NVP的宏替换Android端下的发行包体积大概减少了500KB目前的消息处理框架中处理一次消息的平均时间由100us降低到了25us代码实现约300行更轻量级
未来还能做什么
由于当前项目的原因重新实现的序列化还没有支持转储-恢复指针所指向的内存数据但当前的设计框架已经考虑了这种拓展性未来会考虑支持。
总结
泛型编程能够大幅提高开发效率尤其是在代码重用方面能发挥其优势同时由于其类型推导及生成代码均在编译期完成并不会降低性能序列化对于需要进行转储-恢复的解耦处理以及协助定位异常和崩溃的原因分析具有重要作用利用C及模板自身的语言特性优势结合合理的架构设计即易于拓展又能尽量避免过度设计
原文链接 本文为云栖社区原创内容未经允许不得转载。
