Sorry it took me so long to reply; I was out of town. Nitay Joffe wrote:
Would you please post the compiler errors?
Sure, here is sample code that causes the error:
#include <iosfwd> #include <boost/iostreams/categories.hpp> #include <boost/iostreams/stream.hpp>
struct MyDevice { typedef char char_type; typedef boost::iostreams::source_tag category;
std::streamsize read(char *s, std::streamsize n) { return n; } };
typedef boost::iostreams::stream<MyDevice> MyStream;
int main() { MyDevice d; MyStream s(d, (std::streamsize)500); return 0; }
And here are the compile errors:
g++ a.cc k/usr/include/boost/iostreams/stream.hpp: In constructor 'boost::iostreams::stream<Device, Tr, Alloc>::stream(U100&, const U0&) [with U100 = MyDevice, U0 = std::streamsize, Device = MyDevice, Tr = std::char_traits<char>, Alloc = std::allocator<char>]': a.cc:18: instantiated from here /usr/include/boost/iostreams/stream.hpp:110: error: no matching function for call to 'MyDevice::MyDevice(MyDevice&, const long int&)' a.cc:5: note: candidates are: MyDevice::MyDevice() a.cc:5: note: MyDevice::MyDevice(const MyDevice&) make: *** [all] Error 1
Okay, I see the problem now; the compiler is picking up one of the templated forwarding constructors instead of the primary constructor, since the type of the buffer size is not an exact match.
I believe the culprit is the file iostreams/detail/push_params.hpp, which defines the buffer and pback size using:
#define BOOST_IOSTREAMS_PUSH_PARAMS() \ , int buffer_size = -1 , int pback_size = -1 \ /**/
This macro is then used by stream and friends in their constructor declarations. On 64 bit machines std::streamsize is a long int, so the constructor parameters do not match up and compilation fails.
I remember using int here so that users could write MyStream(myDevice, 500); instead of MyStream(myDevice, (streamsize) 500); I guess it didn't occur to me that users would read the documentation and cast the parameter to the appropriate type :-) I documented the parameters as having type streamsize because the library uses that type for buffer sizes. I could change the documentation to use "int", but I think I'd like to make both types work here, so probably it would be best to disable the forwarding constructors if the first parameter is an exact match for the template parameter T and the second parameter is integral. I've opened a ticket: http://article.gmane.org/gmane.comp.lib.boost.user/33728. Thanks for reporting this issue.
Thanks, -n
-- Jonathan Turkanis CodeRage http://www.coderage.com