the <boost/detail/iomanip.hpp> header (please use it)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Linux, both clang and icc use GNU's C++ standard library by default. As of version 4.5 of GNU's stdlib, a new implementation of the <iomanip> header has been added, which makes use of C++0x features which only GCC supports (the latest versions of clang, e.g. a very recent nightly build, might work; intel certainly won't). The refactored <iomanip> header in GNU's stdlib does not detect C++0x support and fallback on the old C++98 friendly code, which unfortunately leaves clang-linux and intel-linux users in a bit of a bind. In particular, this plagues clang users on Linux as clang will use the latest available version of the GNU stdlib by default, meaning most users cannot have both gcc-4.5 and clang installed without problems. I have implemented the <iomanip> header in <boost/detail/iomanip.hpp>, under the boost::detail namespace (to avoid conflicts with system <iomanip> headers that users/other code might include). The implementation conforms to the C++03 standard (at least, I'm fairly confident it is standard compliant - reviews and feedback would be welcome). I just committed (r68140) a patch which replaces the use of <iomanip> with <boost/detail/iomanip.hpp>. I've tested on a few different compilers, and I'm pretty sure there are no regressions. If it does cause any problems, please let me know. This touches a few libraries, all in trivial ways. My apologizes to any maintainers I may have offended; please feel free to revert the relevant part of the commit (r68140) if you'd rather not have it in your library. P.S. For maximum portability, please use <boost/detail/iomanip.hpp> in Boost code in the future! - -- Bryce Lelbach aka wash boost-spirit.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAk0vurkACgkQ9cB/V3/s9Exh0gCdF5vcDD0DfyONhrob4YFVBZzO 2KwAoIqFS06nk5TV98K0jea1rTj6FkHF =QGJS -----END PGP SIGNATURE-----
On 1/14/2011 9:53 AM, Bryce Lelbach wrote:
I have implemented the <iomanip> header in <boost/detail/iomanip.hpp>, under the boost::detail namespace (to avoid conflicts with system <iomanip> headers that users/other code might include). The implementation conforms to the C++03 standard (at least, I'm fairly confident it is standard compliant - reviews and feedback would be welcome). I just committed (r68140) a patch which replaces the use of <iomanip> with <boost/detail/iomanip.hpp>. I've tested on a few different compilers, and I'm pretty sure there are no regressions. If it does cause any problems, please let me know.
This touches a few libraries, all in trivial ways. My apologizes to any maintainers I may have offended; please feel free to revert the relevant part of the commit (r68140) if you'd rather not have it in your library.
Thank you for doing this! Please be sure to make a note to merge it to release when the trunk tests have cycled. -- Eric Niebler BoostPro Computing http://www.boostpro.com
Bryce Lelbach wrote:
On Linux, both clang and icc use GNU's C++ standard library by default. As of version 4.5 of GNU's stdlib, a new implementation of the <iomanip> header has been added, which makes use of C++0x features which only GCC supports (the latest versions of clang, e.g. a very recent nightly build, might work; intel certainly won't). The refactored <iomanip> header in GNU's stdlib does not detect C++0x support and fallback on the old C++98 friendly code, which unfortunately leaves clang-linux and intel-linux users in a bit of a bind. In particular, this plagues clang users on Linux as clang will use the latest available version of the GNU stdlib by default, meaning most users cannot have both gcc-4.5 and clang installed without problems.
I have implemented the <iomanip> header in <boost/detail/iomanip.hpp>, under the boost::detail namespace (to avoid conflicts with system <iomanip> headers that users/other code might include).
Is this something that we really need to address? This problem has much wider scope than just Boost, and is of a temporary nature.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 14 Jan 2011 17:08:27 +0200 "Peter Dimov" <pdimov@pdimov.com> wrote:
Is this something that we really need to address? This problem has much wider scope than just Boost, and is of a temporary nature.
*shrugs*. Judgement call, really. There's two types of bugs in Boost - bugs that we can fix without massive upheaveal/breaking other stuff, and bugs that we can't. This falls into the category of easy and trivial to fix on our end, so I did. - -- Bryce Lelbach aka wash boost-spirit.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAk0wg58ACgkQ9cB/V3/s9EzIYACfUmQusvK1XpmuZ9yyeKoHP3uQ 22EAoJsdsZuHAgLSX3pdDjo5g168rtv5 =pSCO -----END PGP SIGNATURE-----
AMDG On 1/14/2011 9:10 AM, Bryce Lelbach wrote:
Is this something that we really need to address? This problem has much wider scope than just Boost, and is of a temporary nature. *shrugs*. Judgement call, really. There's two types of bugs in Boost - bugs
On Fri, 14 Jan 2011 17:08:27 +0200 "Peter Dimov"<pdimov@pdimov.com> wrote: that we can fix without massive upheaveal/breaking other stuff, and bugs that we can't. This falls into the category of easy and trivial to fix on our end, so I did.
Just because it's easy, doesn't mean it's the right thing to do. Your patch makes the code uglier, although not by much. You should also be more careful that you actually commit exactly what you intend to commit, especially with such widespread changes. In addition to the Jamfile changes which you noticed and reverted, you committed some workarounds for pathscale. I would not have approved those particular changes if they were for my library, simply because I really, *really* dislike scattering #ifdefs around. In Christ, Steven Watanabe
At Fri, 14 Jan 2011 12:39:45 -0800, Steven Watanabe wrote:
On 1/14/2011 9:10 AM, Bryce Lelbach wrote:
Is this something that we really need to address? This problem has much wider scope than just Boost, and is of a temporary nature. *shrugs*. Judgement call, really. There's two types of bugs in Boost - bugs
On Fri, 14 Jan 2011 17:08:27 +0200 "Peter Dimov"<pdimov@pdimov.com> wrote: that we can fix without massive upheaveal/breaking other stuff, and bugs that we can't. This falls into the category of easy and trivial to fix on our end, so I did.
Just because it's easy, doesn't mean it's the right thing to do. Your patch makes the code uglier, although not by much.
You should also be more careful that you actually commit exactly what you intend to commit, especially with such widespread changes. In addition to the Jamfile changes which you noticed and reverted, you committed some workarounds for pathscale. I would not have approved those particular changes if they were for my library, simply because I really, *really* dislike scattering #ifdefs around.
This sounds problematic. Are these changes in trunk or release? If in release, can they be pulled out until after the release, so we have time to evaluate them, please? -- Dave Abrahams BoostPro Computing http://www.boostpro.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Steven is talking about two separate commits here, which are entirely unrelated. The changes described in the first post in this thread are in the trunk. - -- Bryce Lelbach aka wash boost-spirit.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAk0wygwACgkQ9cB/V3/s9EwXggCeJtmy7M156FYo66E5GmDTy/IQ dCIAmgKb8zPmsbqMSmdoz4n9FBl1yauV =dm0T -----END PGP SIGNATURE-----
AMDG On 1/14/2011 2:11 PM, Bryce Lelbach wrote:
Steven is talking about two separate commits here, which are entirely unrelated.
No. I am talking about a single commit, which should have been two unrelated commits. See https://svn.boost.org/trac/boost/changeset/68140/trunk/libs/exception/test/c... for some of the extras. In Christ, Steven Watanabe
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 14 Jan 2011 14:32:08 -0800 Steven Watanabe <watanabesj@gmail.com> wrote: Ah, my apologizes. Missed that. - -- Bryce Lelbach aka wash boost-spirit.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAk0wz/EACgkQ9cB/V3/s9Ew/yQCfd4JI0dQiLU/CbNyQwbCILgUC ZbsAn3Rfik8dtJNQFwEU9nWPx0nWWSsz =8En8 -----END PGP SIGNATURE-----
AMDG On 1/13/2011 6:53 PM, Bryce Lelbach wrote:
This touches a few libraries, all in trivial ways. My apologizes to any maintainers I may have offended; please feel free to revert the relevant part of the commit (r68140) if you'd rather not have it in your library.
If you have any concern that your patch might offend someone, you really should ask first. In Christ, Steven Watanabe
AMDG On 1/14/2011 12:20 PM, Steven Watanabe wrote:
On 1/13/2011 6:53 PM, Bryce Lelbach wrote:
This touches a few libraries, all in trivial ways. My apologizes to any maintainers I may have offended; please feel free to revert the relevant part of the commit (r68140) if you'd rather not have it in your library.
If you have any concern that your patch might offend someone, you really should ask first.
FWIW, seeing anyone apply boost-wide changes, no matter how simple, without prior discussion makes me very nervous. In Christ, Steven Watanabe
On Jan 14, 2011, at 12:30 PM, Steven Watanabe wrote:
On 1/14/2011 12:20 PM, Steven Watanabe wrote:
On 1/13/2011 6:53 PM, Bryce Lelbach wrote:
This touches a few libraries, all in trivial ways. My apologizes to any maintainers I may have offended; please feel free to revert the relevant part of the commit (r68140) if you'd rather not have it in your library.
If you have any concern that your patch might offend someone, you really should ask first.
FWIW, seeing anyone apply boost-wide changes, no matter how simple, without prior discussion makes me very nervous.
Three days before code freeze for a release, no less. -- Marshall
AMDG On 1/13/2011 6:53 PM, Bryce Lelbach wrote:
On Linux, both clang and icc use GNU's C++ standard library by default. As of version 4.5 of GNU's stdlib, a new implementation of the<iomanip> header has been added, which makes use of C++0x features which only GCC supports (the latest versions of clang, e.g. a very recent nightly build, might work; intel certainly won't). The refactored<iomanip> header in GNU's stdlib does not detect C++0x support and fallback on the old C++98 friendly code, which unfortunately leaves clang-linux and intel-linux users in a bit of a bind. In particular, this plagues clang users on Linux as clang will use the latest available version of the GNU stdlib by default, meaning most users cannot have both gcc-4.5 and clang installed without problems.
I have implemented the<iomanip> header in<boost/detail/iomanip.hpp>, under the boost::detail namespace (to avoid conflicts with system<iomanip> headers that users/other code might include). The implementation conforms to the C++03 standard (at least, I'm fairly confident it is standard compliant - reviews and feedback would be welcome).
Unfortunately, conforming to the standard isn't good enough. I think you just broke Codegear support in some places. After thinking about this some more, I think this is the wrong solution to the problem. Those who need to use this configuration should add a working iomanip to their compiler's search path. I am in favor of reverting this patch entirely. In Christ, Steven Watanabe
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 14 Jan 2011 17:12:32 -0800 Steven Watanabe <watanabesj@gmail.com> wrote:
Unfortunately, conforming to the standard isn't good enough. I think you just broke Codegear support in some places.
Unfortunately I don't have Codegear available to test with locally. Can you link me to the regressions you think this has caused? I'm looking through them right now, not seeing anything. Feel free to revert at your own discretion. I would argue, though, that by the same logic, boost::detail::numeric_traits, boost::detail::iterator_traits, etc, shouldn't be used. - -- Bryce Lelbach aka wash boost-spirit.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAk0w/RUACgkQ9cB/V3/s9EzSNgCfc4+WbvjQ31G+uFF/D9SWvHsb GEgAn1S6EEeXVFwe6TMjvzonByTj/qLz =mZ8t -----END PGP SIGNATURE-----
AMDG On 1/14/2011 5:49 PM, Bryce Lelbach wrote:
On Fri, 14 Jan 2011 17:12:32 -0800 Steven Watanabe<watanabesj@gmail.com> wrote:
Unfortunately, conforming to the standard isn't good enough. I think you just broke Codegear support in some places. Unfortunately I don't have Codegear available to test with locally. Can you link me to the regressions you think this has caused? I'm looking through them right now, not seeing anything.
Feel free to revert at your own discretion.
Okay. I will.
I would argue, though, that by the same logic, boost::detail::numeric_traits, boost::detail::iterator_traits, etc, shouldn't be used.
boost::detail::numeric_traits does not replace anything in the standard. I consider boost::detail::iterator_traits to be obsolete. However, even if someone wanted to use it, the situation is a bit different, since some of the problems that it avoids are not transient, and replacing iterator is not a viable solution. Anyone planning to use your setup with a broken iomanip for the long term is just insane, and I see no reason to support it. If you put this in, we'll end up with code that nobody needs lying around forever. In Christ, Steven Watanabe
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ah, I see it. I'll commit a fix for that to <boost/detail/iomanip.hpp>. Thanks for mentioning it. :) - -- Bryce Lelbach aka wash boost-spirit.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAk0w/w0ACgkQ9cB/V3/s9ExEzgCfTTYeCSXY1WRNNlcrpl+3nT1I QdEAoJ4XWSQ3rh3QOyJg1BSjg+Bdgu9t =EzA3 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Unfortunately, conforming to the standard isn't good enough. I think you just broke Codegear support in some places.
I should've thought of this earlier - <boost/detail/iomanip.hpp> will now include <iomanip> and bring the <iomanip> functions into the boost::detail namespace if not on clang- or intel-linux. - -- Bryce Lelbach aka wash boost-spirit.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAk0xBYMACgkQ9cB/V3/s9EwX8gCfRcH3UegyX8ow2GfdGQGv+DU/ ejcAn38ZML5eoAwcnFqBiX6TpkgQMDjA =UssO -----END PGP SIGNATURE-----
participants (6)
-
Bryce Lelbach -
Dave Abrahams -
Eric Niebler -
Marshall Clow -
Peter Dimov -
Steven Watanabe