[iostreams] #2406: implementation in header causes link errors

Looking at Trac, I've run into the bug above, which seems both fairly severe and easy to fix, so I took the liberty to commit a patch: https://svn.boost.org/trac/boost/changeset/53427 I've tested it on Linux. Can somebody give it a try on Windows? While I've added necessary BOOST_IOSTREAMS_DECL, I might have missed something. Thanks, Volodya

Vladimir Prus wrote:
Looking at Trac, I've run into the bug above, which seems both fairly severe and easy to fix, so I took the liberty to commit a patch:
https://svn.boost.org/trac/boost/changeset/53427
I've tested it on Linux. Can somebody give it a try on Windows? While I've added necessary BOOST_IOSTREAMS_DECL, I might have missed something.
Has anyone tested this on Windows for you yet? Before testing your patch, I tried to reproduce #2406 on Windows using MSVC 7.1 but was unable to do so with Boost_1_39_0. Perhaps my interpretation of the issue, and hence my test case is incorrect. Case #2406 says: "gzip.hpp has some implementation in the header which will cause link errors if the component is used in more than one place" My test case consisted of a main.cpp which included gzip.hpp and a second module which also included gzip.hpp. In both modules, they did something like: std::string str("This is my Test file\n"); io::filtering_ostream out; out.push(io::gzip_compressor()); out.push(io::file_sink("TestFile.gz", std::ios_base::out | std::ios_base::binary)); out.write(str.c_str(), str.size()); Should I be getting the link error? ... or is there some other way to trigger this issue? Once I can reproduce it, I would be happy to try it again on trunk which has your patch applied... assuming someone has not already confirmed it for you.
participants (2)
-
eg
-
Vladimir Prus