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: Christoper Friedt <chrisfriedt@…> 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 Christoper Friedt <chrisfriedt@…>, 5 years ago

The expected output should end with "created istream_iterator!" but instead ends (hangs) with "creating istream_iterator..".

comment:2 by Christoper Friedt <chrisfriedt@…>, 5 years ago

comment:3 by Christoper Friedt <chrisfriedt@…>, 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.

Note: See TracTickets for help on using tickets.