Boost release 1.52.0 beta 1 is now available from SourceForge See https://sourceforge.net/projects/boost/files/boost/1.52.0.beta.1/ This release contains numerous enhancements and bug fixes for existing libraries. For details of what's in the release, see http://www.boost.org/users/history/version_1_52_0.html. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team
Le 09/10/12 21:55, Daniel James a écrit :
Boost release 1.52.0 beta 1 is now available from SourceForge
See https://sourceforge.net/projects/boost/files/boost/1.52.0.beta.1/
This release contains numerous enhancements and bug fixes for existing libraries.
For details of what's in the release, see http://www.boost.org/users/history/version_1_52_0.html.
Hi, please could you add the following for Boost.Ratio [*Features:] * Replace the short_name and long_name functions by symbol and prefix functions respectively. [*Deprecated:] * The ratio_string<>::short_name and ratio_string<>::long_name are deprecated. Use ratio_string<>::symbol and ratio_string<>::prefix respectively. These functions be removed in 1.55. and the following fixes for Boost.Ratio and Boost.Chrono if I'll be able to merge https://svn.boost.org/trac/boost/changeset/80897 and https://svn.boost.org/trac/boost/changeset/80896 as suggested by Eric. // Ratio [*Fixes:] * [@http://svn.boost.org/trac/boost/ticket/7478 #7478] Compiles fails with compilers supporting char16_t and char32_t fails if the library doesn't provides std::u16string and std::u32string. Currently there are no macros BOOST_NO_CXX11_U16STRING and BOOST_NO_CXX11_U32STRING signaling that the standard library doesn't provides std::u16string or std::u32string. The committed change avoids the compile error when Boost.Config will provide these macros. In the mean time the user needs to define them explicitly while using Boost.Ratio in these conditions. // Chrono * [@http://svn.boost.org/trac/boost/ticket/7479 #7479] Compiles fails with compilers supporting constexpr fails if the standard library doesn't provides the constexpr interface Thanks, Vicente
On 10/9/2012 2:13 PM, Vicente J. Botet Escriba wrote:
and the following fixes for Boost.Ratio and Boost.Chrono if I'll be able to merge https://svn.boost.org/trac/boost/changeset/80897 and https://svn.boost.org/trac/boost/changeset/80896 as suggested by Eric.
I just sent a msg letting folks know the release branch is open for bug fixes. Feel free to merge these yourself. Thanks for your patience. -- Eric Niebler BoostPro Computing http://www.boostpro.com
On 9 October 2012 22:13, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
Currently there are no macros BOOST_NO_CXX11_U16STRING and BOOST_NO_CXX11_U32STRING signaling that the standard library doesn't provides std::u16string or std::u32string. The committed change avoids the compile error when Boost.Config will provide these macros. In the mean time the user needs to define them explicitly while using Boost.Ratio in these conditions.
This should go in the library's documentation. The release notes are meant to be a summary, if more detail is required then link to the documentation. Btw. IMO you shouldn't require the user to define macros just to be able to compile the library, is u32string support really that important?
Le 10/10/12 00:45, Daniel James a écrit :
On 9 October 2012 22:13, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
Currently there are no macros BOOST_NO_CXX11_U16STRING and BOOST_NO_CXX11_U32STRING signaling that the standard library doesn't provides std::u16string or std::u32string. The committed change avoids the compile error when Boost.Config will provide these macros. In the mean time the user needs to define them explicitly while using Boost.Ratio in these conditions. This should go in the library's documentation. The release notes are meant to be a summary, if more detail is required then link to the documentation. Okay. Btw. IMO you shouldn't require the user to define macros just to be able to compile the library, is u32string support really that important?
Well, support for u16string and u32 string has been delivered long time ago, so removing them seems not an alternative, or is it? I have proposed a patch to Boost.Config that I expect will be available for the next release. The case where this is needed is a corner case IMO, as the user is using c++11 without a c++ standard library. I know clang is the typical example, but the user can install libc++ which is also free. Best, Vicente
On 10 October 2012 00:06, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
Okay.
I've only checked in the changes that are already in the beta, I'll deal with the others later, I need to somehow make it clear that they're not in the actual beta.
Btw. IMO you shouldn't require the user to define macros just to be able to compile the library, is u32string support really that important?
Well, support for u16string and u32 string has been delivered long time ago, so removing them seems not an alternative, or is it?
Then I'd put some sort of special case for the problematic standard library myself, but if you feel that's not worth it, then it's your decision.
Le 10/10/12 10:24, Daniel James a écrit :
Okay. I've only checked in the changes that are already in the beta, I'll deal with the others later, I need to somehow make it clear that
On 10 October 2012 00:06, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote: they're not in the actual beta.
Btw. IMO you shouldn't require the user to define macros just to be able to compile the library, is u32string support really that important?
Well, support for u16string and u32 string has been delivered long time ago, so removing them seems not an alternative, or is it? Then I'd put some sort of special case for the problematic standard library myself, but if you feel that's not worth it, then it's your decision.
Oh, I see. Instead of using the future BOOST_NO_CXX11_U16STRING I can use my own macro that is defined when compiling with the already identified library. I will made the update as soon as possible hopping it could go to the release. Thanks, Vicente
The following bug that I just finished tracking down and reporting: https://svn.boost.org/trac/boost/ticket/7499 call_once doesn't call even once is, IMO, a serious regression that should be a blocker for releasing 1.52.
Le 11/10/12 22:50, Kim Barrett a écrit :
The following bug that I just finished tracking down and reporting:
https://svn.boost.org/trac/boost/ticket/7499 call_once doesn't call even once
is, IMO, a serious regression that should be a blocker for releasing 1.52.
As said in the preceding post, I will take care of it soon. Best, Vicente
participants (4)
-
Daniel James -
Eric Niebler -
Kim Barrett -
Vicente J. Botet Escriba