I have an application which uses several files to store its data.
The data is organized to store all current data like this, and additionally the data is moved to a single file after a specific time interval to be able to back it up. This single file then contains all data for the time interval like this:
Suppose the data are stored in file1, ..., file8.
The single file has all data for the time interval from file1, then from file2, ...
The data sections may be addressed via an offset into the file plus a length of each section to identify the end.
In the application, I must be able to access data from the single file as well as from the multiple files. I was thinking of hiding the single file in a kind of a wrapper of an std::ifstream with a buffer that is supplied with the offset of the data and the length and thus models a single file.
In other words, I have 8 std::fstreams in the application, and when I access the single file, I create 8 fstreams with buffers "pointing" to the separate data sections.
My first thought was to create my own streambuf-derived class to achieve this. I am currently looking at boost::Iostreams, but am not sure if that may provide a solution.
Does anyone here have a comment on my approach?
can't you just open the same file 8 times and use istream::seekg on each stream accordingly ? the only caveat being that any code relying on eof for each stream to detect the end of the data would not work anymore ... if this is an issue for you then, yes, you can use boost iostream and write a so called "Source" model: you could just store a copy of the original stream in the said source model, calling seekg during construction and forwarding the read() call with eof signaled when the full data section has been retrieved. Of course, if you need a bidirectional or seekable stream then things get more complex, see the boost docs for details ...
Yes, opening the file n times would be simple, but I want to get rid of the eof check which would involve checking if the data section has reached its end. I do need a seekable stream, I will have a closer look to boost.
Thanks for your comment,
We have been using a sort of custom "restriction" wrapper class for encapsulating parts of streams, and i was about to propose that approach....but
it looks like we can drop our code and move to restriction<>, too...thanks!