Iostreams Code converter bug
I've been trying to patch up a bug in iostreams::code_converter but have run in to a lot of trouble understanding what a lot of the macros do. First I'll summarize what the bug is. The documentation for iostreams::code_converter states that the constructor code_converter(const Device& dev, std::streamsize buffer_size = default_value); uses the buffer_size parameter to create a buffer that buffers up data before sending it out along its way. What I've noticed is that somewhere inside the macros that generate the constructors the value is discarded or sent somewhere it shouldn't be going. This means that the default value is always used. For my implementation, 128 bytes. Here is what I've tracked down so far. The code_converter constructors are generated at boost/iostreams/code_converter.hpp:275 which calls the BOOST_IOSTREAMS_FORWARD macro at boost/iostreams/detail/forward.hpp:44. The lines 45-56 make sense to me but 57-64 is where I start to get lost. An interesting thing is that if I comment out the stuff on lines 57-64, things work perfectly. The value that I pass to buffer_size is used and the buffer is exactly the size I want it to be. I'm sure some other facility of iostreams gets broken though. What it seems is that the constructors defined on lines 45-48 somehow get "replaced" or something along those lines by the BOOST_IOSTREAMS_FORWARDING_CTOR macro. Although there is commenting explaining what BOOST_IOSTREAMS_FORWARD does, there is no comments explaining what BOOST_IOSTREAMS_FORWARDING_CTOR is and what all that macro code actually does. I can't run it through a debugger so I've hit a wall as far as fixing this. Can anyone offer any insight as to what is going on here? What is this BOOST_IOSTREAMS_FORWARDING_CTOR macro? -- Eddie Carle
On 3 February 2011 00:35, Eddie Carle <eddie@erctech.org> wrote:
Although there is commenting explaining what BOOST_IOSTREAMS_FORWARD does, there is no comments explaining what BOOST_IOSTREAMS_FORWARDING_CTOR is and what all that macro code actually does. I can't run it through a debugger so I've hit a wall as far as fixing this. Can anyone offer any insight as to what is going on here? What is this BOOST_IOSTREAMS_FORWARDING_CTOR macro?
The best way of finding out what complicated macros do is to run it through the preprocessor, find the generated code and the run that through a code beautifier if necessary. In this case it seems to be creating constructors which take a variable number of arguments for forwarding to the device constructor, followed by the buffer size. I guess that the problem is that the buffer size argument is actually an int (see BOOST_IOSTREAMS_CONVERTER_PARAMS), and that 'std::streamsize' is something else (try casting the buffer size to an int when constructing the class). So since the buffer size parameter is optional, and the template arguments for forwarding to the device constructor are probably a better match, what you want to be the buffer size is used as a parameter for the device constructor. I'm not sure what a good solution is. Having variadic arguments followed by an optional argument is a really bad idea, it's far too ambiguous. Since it isn't documented, it might be possible just to remove the feature but that could cause problems for other people. I'd be tempted to create a new class with a simpler interface but the same implementation behind it. Daniel
On Thu, 2011-02-03 at 12:07 +0000, Daniel James wrote:
try casting the buffer size to an int when constructing the class
Well I'll be, that fixed it. All along that is what it was. Casting it to an int fixed everything. Boy I wish that had become evident sooner. Thanks! -- Eddie Carle
On 3 February 2011 19:33, Eddie Carle <eddie@erctech.org> wrote:
On Thu, 2011-02-03 at 12:07 +0000, Daniel James wrote:
try casting the buffer size to an int when constructing the class
Well I'll be, that fixed it. All along that is what it was. Casting it to an int fixed everything. Boy I wish that had become evident sooner. Thanks!
If it wasn't clear, that's a workaround, not a fix. I don't want to change iostream's API though, so I'll just change the documentation for 1.47. Daniel
participants (2)
-
Daniel James -
Eddie Carle