|
Boost Users : |
Subject: Re: [Boost-users] [iostreams] filtering_istream not working as intended..
From: mmocny (mmocny_at_[hidden])
Date: 2009-06-16 20:21:19
Hello all,
I am running into some odd "quirks" of the filtering_istream in the
boost::iostreams library.
Perhaps I am just using it wrong, but all code compiles, and does _almost_
what I would expect it to.
Example Code:
#include <boost/iostreams/tee.hpp>
#include <boost/iostreams/invert.hpp>
#include <boost/iostreams/device/file.hpp>
#include <boost/iostreams/filtering_stream.hpp>
#include <iostream>
int main()
{
boost::iostreams::file log_file("sample.txt", std::ios::trunc);
boost::iostreams::filtering_istream in;
in.push( boost::iostreams::invert(boost::iostreams::tee(log_file)) )
/* this part is optional */
in.push( std::cin );
std::string s;
int i;
/* step 1 */
getline(std::cin,s); /* note: std::cin as istream passed to getline */
std::cin >> i;
std::cin.ignore( std::numeric_limits<std::streamsize>::max(), '\n' );
std::cout << s << std::endl << i << std::endl;
/* step 2 */
getline(in,s); /* note: filtering_istream wrapping std::cin passed here */
in >> i;
std::cin.ignore( std::numeric_limits<std::streamsize>::max(), '\n' );
std::cout << s << std::endl << i << std::endl;
/* I would expect step 1 and step 2 to behave exactly the same
(except for the loggin) */
}
As documented, I would expect the two input blocks to exhibit the exact same
behavior.
Unfortunately, on my platform anyway ( gcc 4.3.3 on 64 bit linux ) - and
verified by another user ( also on linux 64 bit, gcc 4.4 ) - that the two
code blocks not only differ, but differ in odd ways.
The filtering_istream blocks on input, and will not resume until *4* EOF
characters are sent. If I remove the invert(tee(log_file)) only *2* EOF
need to be sent.
First off, I do not know why it is blocking (perhaps this is expected from a
filtering_istream which expects to read the entire stream to EOF). I have
not found this documented anywhere.
Either way, the fact that multiple EOF's need to be sent, and the fact that
that number differs depending on the pipeline, leads me to think there is
either a bug or I am not using something as intended.
Thanks for any help!
-Michal
p.s. My requirements are only to create an istream which sends what is read
from standard input to a log file, while still having the input available
for processing by the application. Maybe can suggest another way to solve
the problem?
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net