protobuf 之诡异的文件流与压缩

only_a_Heroic_car

已于 2024-01-23 10:52:25 修改

阅读量489

点赞数 8

分类专栏： protobuf C++ 文章标签： protobuf c++

于 2024-01-22 22:30:00 首次发布

本文链接：https://blog.csdn.net/only_a_Heroic_car/article/details/135744722

版权

C++ 同时被 2 个专栏收录

18 篇文章 0 订阅

订阅专栏

protobuf

2 篇文章 0 订阅

订阅专栏

本文比较了GzipOutputStream和OstreamOutputStream在文件流处理中的行为，指出OstreamOutputStream没有显式Flush方法，因为早期的编程趋势倾向于在对象析构时自动释放资源。作者还展示了如何在protobuf中使用Ostream进行序列化操作。

摘要由CSDN通过智能技术生成

内容较干。文章大概需要花费5分钟简单了解下。

1、Gzip

直接看源码头文件如上图。压缩对象 GzipOutputStream ，通过函数操作可以看到整个文件流是比较完整并清晰。
因为它显示清晰包含了从初始化到 flush 到 close 的显示调用

2、Ostream

源码头文件

直接看源码头文件如上。流对象 OstreamOutputStream ，通过函数操作可以看到整个文件流很奇怪。奇怪在于它只有流函数，没有Flush。

为啥没有Flush呢？

听网友们的意思是：几年前流行面向对象和 RAII，很多对象只能在析构函数中进行资源回收，Ostream 干了这个事…所以说需要加大括号使用局部变量来自动析构Flush，这样才能提前释放Ostream触发Flush成功写入

所以你的代码有bug吗？

	std::ofstream output;
	func()
	{
		/*
		***
		*/
		{// 析构中自动flush
			google::protobuf::io::OstreamOutputStream raw_output(&output);
			google::protobuf::io::CodedOutputStream coded_output(&raw_output);
	
			auto user_data = response->userdata();
			int fid = (int)user_data;
			coded_output.WriteVarint32(fid);
			coded_output.WriteVarint32(response->ByteSizeLong());
			response->SerializeToCodedStream(&coded_output);
	
		}
	}