Opened 5 years ago
Last modified 5 years ago
#13207 new Bugs
boost::spirit::istream_iterator unusable with boost::asio::ip::tcp::iostream
Reported by: | Owned by: | Joel de Guzman | |
---|---|---|---|
Milestone: | To Be Determined | Component: | spirit |
Version: | Boost 1.65.0 | Severity: | Showstopper |
Keywords: | istream_iterator | Cc: |
Description
Hi,
I'm really looking forward to using boost::spirit in my next project. Unfortunately, I seem to have hit a roadblock in that the boost::spirit::istream_iterator constructor completely locks up when it is passed a boost::asio::ip::tcp::iostream reference.
I come from a (much stronger) C background, so perhaps I'm missing the greater picture, but in the "spirit" of a C++ stream-based API, I would have thought that any input stream would work with spirit's forward iterator - at least that's how I interpreted the documentation.
A really simple example is the following:
#include <boost/asio.hpp> #include <boost/spirit/include/support_istream_iterator.hpp> #include <iostream> int main( int argc, char *argv[] ) { static const int port = 443; if ( 2 != argc ) { std::cout << "usage: " << argv[ 0 ] << " <fqdn>" << std::endl; std::cout << std::endl; std::cout << "where <fqdn> is e.g. www.google.ca" << std::endl; return 0; } std::string fqdn( argv[ 1 ] ); std::cout << "creating fds.." << std::endl; boost::asio::ip::tcp::iostream fds( fqdn, std::to_string( port ) ); if ( ! fds ) { std::cerr << "unable to create fds: " << fds.error().message() << std::endl; return 1; } std::cout << "creating istream_iterator.." << std::endl; boost::spirit::istream_iterator begin( fds ); std::cout << "created istream_iterator!" << std::endl; return 0; }
Compile with
g++ -std=c++14 -o foo foo.cpp -lboost_system
Any thoughts?
Change History (3)
comment:1 by , 5 years ago
comment:2 by , 5 years ago
I suppose that this might be a hint.
http://www.boost.org/doc/libs/1_52_0/doc/html/boost_asio/example/timeouts/blocking_tcp_client.cpp
comment:3 by , 5 years ago
Ugh... no .. forget it. Following the blocking_tcp_client pattern would require that I wrap my inputstream with some other class, which would kind of defeat the purpose of abstracting it as an inputstream.
The expected output should end with "created istream_iterator!" but instead ends (hangs) with "creating istream_iterator..".