On 9 September 2010 13:11, Hartmut Kaiser <hartmut.kaiser@gmail.com> wrote:
Why has the iostreams::file_descriptor constructor taking a file descriptor (OS handle) being deprecated (BOOST_IOSTREAMS_USE_DEPRECATED)? This seems to be somewhat counter-intuitive to me. Even more as our code depends on this functionality and I see no way to rewrite it in order to accommodate for this change (we're wrapping a pipe handle here).
There are new constructors which provide equivalent functionality. They're mentioned in both the release notes and the documentation. The problem is that the class' close method would close the file descriptor regardless of whether 'close_on_exit' was set. This meant the file descriptors could be unexpectedly closed because iostream calls 'close' elsewhere. It could be changed so that if 'close_on_exit' is false, then close wouldn't close the file descriptor - but it's very likely that there's existing code which relies on the file descriptor getting closed so that would cause resource links. So the new constructors require you to be explicit about whether you want the class to close the file descriptor or not.
The worst is that defining BOOST_IOSTREAMS_USE_DEPRECATED while compiling our application makes the compilation succeed, but linking fails as this function has not been compiled by default into the iostreams library. Regenerating the boost libraries is not an option for us, as we need to rely on pre-installed libraries most of the time (HPC systems have their own weird rules...).
How are you building it? The macro is defined in the iostreams Jamfile. Daniel