Turning off BOOST_IOSTREAMS_HAS_DINKUMWARE_FPOS for MSVC++
Hi folks! As part of a recent cleanup of some of our iostreams bits I removed a double-seek inside std::filebuf. (Previously, std::filebuf didn't take advantage that we know ::fsetpos just accepts a 64 bit number position) Moreover, in previous releases of MSVC++, that still would have been correct; filebuf was getting to the same place in a very indirect way. I know just casting std::fpos to a streamoff works to get the position going back to at least VS 2015, and it probably works a decade earlier than that (though I have not tested). Shame on us for adding a pretty name to std::fpos not depicted in the standard. Would you accept a patch to $\boost\iostreams\detail\config\fpos.hpp adding this guard before attempting to define BOOST_IOSTREAMS_HAS_DINKUMWARE_FPOS? !(_MSVC_STL_VERSION >= 141) I submitted a patch to do that here: https://github.com/boostorg/iostreams/pull/57 Thanks folks! Billy O'Neal Visual C++ Libraries
On 17/04/2018 0:43, Billy O'Neal (VC LIBS) via Boost-users wrote:
Hi folks!
As part of a recent cleanup of some of our iostreams bits I removed a double-seek inside std::filebuf. (Previously, std::filebuf didn’t take advantage that we know ::fsetpos just accepts a 64 bit number position) Moreover, in previous releases of MSVC++, that still would have been correct; filebuf was getting to the same place in a very indirect way.
I know just casting std::fpos to a streamoff works to get the position going back to at least VS 2015, and it probably works a decade earlier than that (though I have not tested). Shame on us for adding a pretty name to std::fpos not depicted in the standard. Would you accept a patch to $\boost\iostreams\detail\config\fpos.hpp adding this guard before attempting to define BOOST_IOSTREAMS_HAS_DINKUMWARE_FPOS?
!(_MSVC_STL_VERSION >= 141)
I submitted a patch to do that here: https://github.com/boostorg/iostreams/pull/57
Shouldn't we check macro is #defined before using it? Best, Ion
On 17/04/2018 21:41, Ion Gaztañaga wrote:
Shouldn't we check macro is #defined before using it?
Any standards-conforming preprocessor should not technically require that (any undefined symbol is evaluated as 0). Though not all are standards-conforming, and some might issue warning diagnostics, so it's still probably a good idea to do so.
participants (3)
-
Billy O'Neal (VC LIBS) -
Gavin Lambert -
Ion Gaztañaga