[iostreams] basic_buffer int usage

Hello, I was working with some boost::iostreams code for compressing and uncompressing streams of data when I encountered an interesting type conversion warning. Within buffer.hpp in the iostreams library (boost/iostreams/detail folder), the constructors accept an int buffer_size and assign it to std::streamsize size_. Upon further investigation, I learned that this was intentional as of r27330 (Log msg: "made all buffer size params ints so that int literals can be used without interfering with overload resolution"). Here is some example code that triggers the same warnings I was receiving: // Tested with boost 1.46.1 // Compiler Microsoft VC2010 SP1. // Compiled with cl /EHsc /W3 repro.cpp #include <boost/iostreams/copy.hpp> #include <boost/iostreams/device/array.hpp> #include <boost/iostreams/filtering_streambuf.hpp> int main (int, char *[]) { static const char b[] = { 'A', 'B', 'C' }; boost::iostreams::array_source as (b, 3); boost::iostreams::filtering_streambuf <boost::iostreams::input> in; in.push (as); // This line generates a 'std::streamsize' to 'int' warning. // See also boost/iostreams/detail/buffer.hpp boost::iostreams::copy (in, std::cout); return 0; } I am not completely sure what overload resolution is taking place, I only see a default constructor and a constructor that takes a buffer size. What am I missing? I posted approximately a week ago on this topic, but I don't think it made it to the list. Forgive me if this is a repost, I modified the content of the message since I learned more about the subject in the meantime. Thanks, Judson Weissert

On 12 August 2011 14:32, Judson Weissert <judson@mfrac.com> wrote:
I am not completely sure what overload resolution is taking place, I only see a default constructor and a constructor that takes a buffer size. What am I missing?
A lot of the classes have macros like this: BOOST_IOSTREAMS_FORWARD( code_converter, open_impl, Device, BOOST_IOSTREAMS_CONVERTER_PARAMS, BOOST_IOSTREAMS_CONVERTER_ARGS ) These generate constructors with different numbers of arguments which are forwarded to the implementation object. The problem is that since they're template based they're often a better match for arguments than the constructor you actually want to use.
participants (2)
-
Daniel James
-
Judson Weissert