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..".