我是新手,它的iostreams包和查找文档有点薄。希望有人会让我直截了当。我正在尝试转换一小段C#流代码,我写了一段时间用于在压缩流中读取。
byte[] data = new byte[length - 1];
file.Read(data, 0, data.Length);
Stream ret = new ZlibStream(new MemoryStream(data), CompressionMode.Decompress, true);
return ret;
来自文件部分的数据被读入内存缓冲区,该内存缓冲区为zlib解压缩程序提供信息。流的消费者会随着时间的推移而接收它,当它完成时将调用Close()
,它与垃圾收集器结合将清理所有资源。 注意:一个重要的区别是我不是要尝试解压缩整个文件,只是其中的一小部分。该文件已被搜索到某个内部位置,并且相对于文件的完整大小,长度较小。
我正试图用Boost在C ++代码中提出最好的等价物。到目前为止,我的道德等同于上述(未经测试):
char * data = new char[length - 1];
_file.read(data, length - 1);
io::stream_buffer<io::basic_array_source<char> > buffer(data, length - 1);
io::filtering_stream<io::input> * in = new io::filtering_stream<io::input>;
in->push(io::zlib_decompressor());
in->push(buffer);
return in;
我假设我可以返回包含在shared_ptr
中的filtering_stream,这样可以避免消费者不必担心删除流,但我也有新的数据缓冲区。理想情况下,我希望消费者只在流上调用close()
,并且某些机制(例如回调)将清理过滤器中的底层资源。要求消费者将流传递给显式释放函数也是可以接受的,但我仍然不完全确定如何首先获取底层数据缓冲区。
也欢迎更清洁的替代解决方案。
更新1
我试图松散地抓住Cat Plus Plus关于std :: vector支持的驱动程序的评论。这不是我所做的,但这是我到目前为止所提出的。在下面的代码中,我有一个boost :: shared_array支持的驱动程序,基于boost驱动程序示例。
namespace io = boost::iostreams;
class shared_array_source
{
public:
typedef char char_type;
typedef io::source_tag category;
shared_array_source (boost::shared_array<char> s, std::streamsize n)
: _data(s), _pos(0), _len(n)
{ }
std::streamsize read (char * s, std::streamsize n)
{
std::streamsize amt = _len - _pos;
std::streamsize result = (std::min)(amt, n);
if (result != 0) {
std::copy(_data.get() + _pos, _data.get() + _pos + result, s);
return result;
}
else {
return -1;
}
}
private:
boost::shared_array<char> _data;
std::streamsize _pos;
std::streamsize _len;
};
然后我有我的函数返回一个流
io::filtering_istream * GetInputStream (...)
{
// ... manipulations on _file, etc.
boost::shared_array<char> data(new char[length - 1]);
_file.read(data.get(), length - 1);
shared_array_source src(data, length - 1);
io::stream<shared_array_source> buffer(src);
io::filtering_istream * in = new io::filtering_istream;
in->push(io::zlib_decompressor());
in->push(buffer);
// Exhibit A
// uint32_t ui;
// rstr->read((char *)&ui, 4);
return in;
}
在我测试程序的主要功能中:
int main () {
boost::iostreams::filtering_istream * istr = GetInputStream();
// Exhibit B
uint32_t ui;
rstr->read((char *)&ui, 4);
return 0;
}
忽略这样一个事实:我正在返回一个永远不会被释放的指针 - 我保持这个尽可能简单。运行时会发生什么?如果我在附录A中取消注释代码,我会在ui
中获得正确的读数。但是当我点击图表B时,我在Boost(有时)深陷,深陷,深陷。好吧废话,我走出范围,事情破了,一些当地人必须解构并弄乱一切。 data
位于shared_array中,in
位于堆上,压缩程序是根据文档构建的。
其中一个boost构造函数或函数是否抓取对堆栈中对象的引用(即io :: stream或filtering_stream的推送)?如果是这种情况,我会回到堆上的非管理对象的方方面面。
答案 0 :(得分:1)
你真的应该避免在堆上分配任何东西。 filtering_stream
可以动态解压缩,因此您无需先替换缓冲区或读取文件内容。代码看起来应该更像这样:
io::filtering_stream stream;
stream.push(io::zlib_decompressor());
stream.push(_file);
如果真的需要在堆上分配它,那么是的,你应该把它包装在一个智能指针中(但是再次,不要先读取文件数据 - 你冒着风险该缓冲区的泄漏,更不用说以这种方式读取大文件可能非常低效。)
答案 1 :(得分:0)
最终,我不得不放弃试图让Boost iostream自己清理干净。虽然创建一个内部使用boost :: shared_array的自定义数组设备解决了我的数据缓冲区留在堆上的问题,但事实证明boost :: iostreams :: filtering_stream / streambuf引用了一个被推入链中的对象,这意味着它正在捕获对堆栈中我的设备的引用(无论如何,我可以从源和行为中推断)。我可以在堆上新建设备,但这只会让我回到原点。
我的以下解决方案将流的创建移动到一个瘦的std :: istream包装器中,然后可以在boost :: shared_ptr中返回,允许在最后一个引用被销毁时清除所有资源。
template <class Compressor>
class CompressedIStream : public std::basic_istream<char, std::char_traits<char> >
{
public:
CompressedIStream (std::istream& source, std::streamsize count)
: _data(new char[count]), _buffer(_data, count), std::basic_istream<char, std::char_traits<char> >(&_filter)
{
source.read(_data, count);
_filter.push(Compressor());
_filter.push(_buffer);
}
virtual ~CompressedIStream ()
{
delete[] _data;
}
private:
char * _data;
io::stream_buffer<io::basic_array_source<char> > _buffer;
io::filtering_istreambuf _filter;
};
boost::shared_ptr<std::istream> GetInputStream (...)
{
// ... manipulations on _file, etc.
typedef CompressedIStream<io::zlib_decompressor> StreamType;
return boost::shared_ptr<StreamType>(new StreamType(_file, length - 1));
}