The problem is:
I have a code that operates on a fully functional istream
. It uses methods like:
istream is;
is.seekg(...) // <--- going backwards at times
is.tellg() // <--- to save the position before looking forward
etc.
These methods are only available for istreams from, say, a file. However, if I use cin
in this fashion, it will not work--cin
does not have the option of saving a position, reading forward, then returning to the saved position.
// So, I can't cat the file into the program
cat file | ./program
// I can only read the file from inside the program
./program -f input.txt
// Which is the problem with a very, very large zipped file
// ... that cannot coexist on the same raid-10 drive system
// ... with the resulting output
zcat really_big_file.zip | ./program //<--- Doesn't work due to cin problem
./program -f really_big_file.zip //<--- not possible without unzipping
I can read cin
into a deque
, and process the deque
. A 1mb deque
buffer would be more than enough. However, this is problematic in three senses:
- I have to rewrite everything to do this with a
deque
- It wont be as bulletproof as just using an
istream
, for which the code has already been debugged - It seems like, if I implement it as a
deque
with some difficulty, someone is going to come along and say, why didn't you just do it like ___
What is the proper/most efficient way to create a usable istream
object, in the sense that all members are active, with a cin
istream
?
(Bearing in mind that performance is important)