Hello everyone, We're coming up to the beta release, so it's time to put together the release notes (although please don't feel you need to wait for me to start). As always you can send them to me, or if you want update them yourself in subversion. The files are at: https://svn.boost.org/svn/boost/website/public_html/live/feed/history/ The actual site won't get updated until I run the update script. You can see the release notes so far at: http://www.boost.org/users/history/version_1_52_0.html As usual, they're not finished yet, and some of the links might not work as the 1.52 documentation won't be uploaded until after the beta is released. thanks, Daniel
Le 30/09/12 14:19, Daniel James a écrit :
Hello everyone,
We're coming up to the beta release, so it's time to put together the release notes (although please don't feel you need to wait for me to start). As always you can send them to me, or if you want update them yourself in subversion. The files are at:
Hi, Please, could you add the following? Best, Vicente * [phrase library..[@/libs/chrono/index.html Chrono]:] * [*New Features:] * [@http://svn.boost.org/trac/boost/ticket/5980 #5980] Enhance chrono I/O with H. Hinnant proposal [@http://home.roadrunner.com/~hinnant/bloomington/chrono_io.html proposal] which has the advantage to provide I/O for system clocks using the Gregorian Calendar. * [@http://svn.boost.org/trac/boost/ticket/5981 #5981] Add i/o state savers for duration and time_point formatting state. * [@http://svn.boost.org/trac/boost/ticket/7059 #7059] Add low level i/o facilities. * [*Deprecated features:] * The chrono i/o version included in Boost.Chrono 1.2.x has been completly refactored in version 2.0.0 * chrono I/O: The manipulators __duration_short, __duration_long are depreceated. You should use the parameterized form __duration_fmt or the renamed manipulators __duration_symbol and __duration_prefix instead. * chrono I/O: The __duration_punct<> facet is depreceated. You should use the __get_duration_style free function to get the informations and use the __duration_units facet for localization purposes. * When BOOST_CHRONO_VERSION==2 the preceding deprecated functions are not available. * [*Fixes:] * [@http://svn.boost.org/trac/boost/ticket/7381 #7381] C++11 compliance: unresolved symbol when assigning a constexpr duration to a non-const local variable. * [*Would not fix:] * [@http://svn.boost.org/trac/boost/ticket/6871 #6871] chrono_io.hpp: operator<<(ostream& os, ...) modifies the state of os. The neww io interface provided in version 2 solves this issue. You should move to the new version. * [phrase library..[@/libs/thread/index.html Thread]:] * [*Deprecated Features]: Deprecated features since boost 1.50 available only until boost 1.55. These deprecated features will be provided by default up to boost 1.52. If you don't want to include the deprecated features you could define BOOST_THREAD_DONT_PROVIDE_DEPRECATED_FEATURES_SINCE_V3_0_0. Since 1.53 these features will not be included any more by default. Since this version, if you want to include the deprecated features yet you could define BOOST_THREAD_PROVIDE_DEPRECATED_FEATURES_SINCE_V3_0_0. These deprecated features will be only available until boost 1.55, that is you have yet 1 year to move to the new features. * Time related functions don't using the Boost.Chrono library, use the chrono overloads instead. Breaking changes when BOOST_THREAD_VERSION==3 (Default value since Boost 1.53): There are some new features which share the same interface but with different behavior. These breaking features are provided by default when BOOST_THREAD_VERSION is 3, but the user can however choose the version 2 behavior by defining the corresponding macro. As for the deprecated features, these broken features will be only available until boost 1.55. * [@http://svn.boost.org/trac/boost/ticket/6229 #6229] C++11 compliance & Breaking change: Rename the unique_future to future following the c++11. * [@http://svn.boost.org/trac/boost/ticket/6266 #6266] C++11 compliance & Breaking change: thread destructor should call terminate if joinable. * [@http://svn.boost.org/trac/boost/ticket/6269 #6269] C++11 compliance & Breaking change: thread move assignment should call terminate if joinable. * [*New Features:] * [@http://svn.boost.org/trac/boost/ticket/4710 #4710] C++11 compliance: Missing async(). * [@http://svn.boost.org/trac/boost/ticket/7283 #7283] C++11 compliance: Add notify_all_at_thread_exit. * [@http://svn.boost.org/trac/boost/ticket/7345 #7345] C++11 compliance: Add noexcept to recursive mutex try_lock. * [*Fixed Bugs:] * [@http://svn.boost.org/trac/boost/ticket/2361 #2361] thread_specific_ptr: document nature of the key, complexity and rationale. * [@http://svn.boost.org/trac/boost/ticket/2797 #2797] Two problems with thread_specific_ptr. * [@http://svn.boost.org/trac/boost/ticket/5274 #5274] failed to compile future.hpp with stlport 5.1.5 under msvc8.1, because of undefined class. * [@http://svn.boost.org/trac/boost/ticket/5431 #5431] compile error in Windows CE 6.0(interlocked). * [@http://svn.boost.org/trac/boost/ticket/5752 #5752] boost::call_once() is unreliable on some platforms. * [@http://svn.boost.org/trac/boost/ticket/7045 #7045] Thread library does not automatically compile date_time. * [@http://svn.boost.org/trac/boost/ticket/7173 #7173] wrong function name interrupt_point(). * [@http://svn.boost.org/trac/boost/ticket/7200 #7200] Unable to build boost.thread modularized. * [@http://svn.boost.org/trac/boost/ticket/7220 #7220] gcc 4.6.2 warns about inline+dllimport functions. * [@http://svn.boost.org/trac/boost/ticket/7238 #7238] this_thread::sleep_for() does not respond to interrupt(). * [@http://svn.boost.org/trac/boost/ticket/7245 #7245] Minor typos on documentation related to version 3. * [@http://svn.boost.org/trac/boost/ticket/7272 #7272] win32/thread_primitives.hpp: (Unneccessary) Warning. * [@http://svn.boost.org/trac/boost/ticket/7284 #7284] Clarify that there is no access priority between lock and shared_lock on shared mutex. * [@http://svn.boost.org/trac/boost/ticket/7329 #7329] boost/thread/future.hpp does not compile on HPUX. * [@http://svn.boost.org/trac/boost/ticket/7336 #7336] BOOST_THREAD_DONT_USE_SYSTEM doesn't work. * [@http://svn.boost.org/trac/boost/ticket/7329 #7349] packaged_task holds reference to temporary. * [@http://svn.boost.org/trac/boost/ticket/7350 #7350] allocator_destructor does not destroy object
Hi, Vicente 2012/10/1 Vicente J. Botet Escriba <vicente.botet@wanadoo.fr>:
Le 30/09/12 14:19, Daniel James a écrit : ...
* [phrase library..[@/libs/thread/index.html Thread]:]
* Time related functions don't using the Boost.Chrono library, use the chrono overloads instead. ...
I could not understand this. What does mean? Thanks, Akira
Le 12/10/12 07:27, Akira Takahashi a écrit :
Hi, Vicente
2012/10/1 Vicente J. Botet Escriba <vicente.botet@wanadoo.fr>:
Le 30/09/12 14:19, Daniel James a écrit : ... * [phrase library..[@/libs/thread/index.html Thread]:]
* Time related functions don't using the Boost.Chrono library, use the chrono overloads instead. ...
I could not understand this. What does mean?
Hi, sorry for the imprecision. I meant that all the interfaces using Boost.DateTime posix_time are now deprecated. From the doc" The time related functions introduced in Boost 1.35.0, using the Boost.DateTime library are deprecated. These include (but are not limited to): boost::this_thread::sleep() thread::timed_join() condition_variable::timed_wait() timed_mutex::timed_lock() " Best, Vicente
On Fri, Oct 12, 2012 at 8:01 PM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
Hi,
sorry for the imprecision. I meant that all the interfaces using Boost.DateTime posix_time are now deprecated. From the doc"
The time related functions introduced in Boost 1.35.0, using the Boost.DateTime library are deprecated. These include (but are not limited to):
boost::this_thread::sleep() thread::timed_join() condition_variable::timed_wait() timed_mutex::timed_lock()
"
Hmm, I don't really like this. I don't want to add a dependency on Boost.Chrono in Boost.Log, which depends on Boost.DateTime anyway. Why are these interfaces deprecated? Why not keep them as they are?
Le 12/10/12 18:18, Andrey Semashev a écrit :
On Fri, Oct 12, 2012 at 8:01 PM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
Hi,
sorry for the imprecision. I meant that all the interfaces using Boost.DateTime posix_time are now deprecated. From the doc"
The time related functions introduced in Boost 1.35.0, using the Boost.DateTime library are deprecated. These include (but are not limited to):
boost::this_thread::sleep() thread::timed_join() condition_variable::timed_wait() timed_mutex::timed_lock()
" Hmm, I don't really like this. I don't want to add a dependency on Boost.Chrono in Boost.Log, which depends on Boost.DateTime anyway. Hi, Why you don't want to depend on Boost.Chrono?
Why are these interfaces deprecated? These interfaces are deprecated since 1.50. IMO the chrono based interfaces replace quite well the date_time based interface, so if the functionality is provided with a better interface, it is normal to deprecate the old one. Why not keep them as they are?
I could keep them, but I would prefer to reduce the code to maintain. Best, Vicente
On Oct 12, 2012 8:35 PM, "Vicente J. Botet Escriba" < vicente.botet@wanadoo.fr> wrote:
Le 12/10/12 18:18, Andrey Semashev a écrit :
Hmm, I don't really like this. I don't want to add a dependency on Boost.Chrono in Boost.Log, which depends on Boost.DateTime anyway.
Hi, Why you don't want to depend on Boost.Chrono?
Because I want to minimize dependencies (especially, binary build dependencies). Unlike Boost.DateTime, Boost.Chrono is not needed by my library, so this would really be a false dependency.
Why are these interfaces deprecated?
These interfaces are deprecated since 1.50. IMO the chrono based interfaces replace quite well the date_time based interface, so if the functionality is provided with a better interface, it is normal to deprecate the old one.
Yes, Boost.Chrono-based interface provides a nice alternative to the Boost.DateTime-based one. But that doesn't make the latter useless. I think it still has its use, at least for backward compatibility and dependency reduction, like in my case.
Why not keep them as they are?
I could keep them, but I would prefer to reduce the code to maintain.
I understand that the dual interface adds more redundancy but does it really require active maintenance? The code has been there for quite some time, it's well tested and doesn't require additional work.
Le 12/10/12 21:51, Andrey Semashev a écrit :
On Oct 12, 2012 8:35 PM, "Vicente J. Botet Escriba" < vicente.botet@wanadoo.fr> wrote:
Le 12/10/12 18:18, Andrey Semashev a écrit :
Hmm, I don't really like this. I don't want to add a dependency on Boost.Chrono in Boost.Log, which depends on Boost.DateTime anyway. Hi, Why you don't want to depend on Boost.Chrono? Because I want to minimize dependencies (especially, binary build dependencies). Me too, I want to limit dependencies :) Unlike Boost.DateTime, Boost.Chrono is not needed by my library, so this would really be a false dependency. If you don't need time related thread facilities you could set BOOST_THREAD_DONT_USE_CHRONO. Would this work for you?
Why are these interfaces deprecated? These interfaces are deprecated since 1.50. IMO the chrono based interfaces replace quite well the date_time based interface, so if the functionality is provided with a better interface, it is normal to deprecate the old one.
Yes, Boost.Chrono-based interface provides a nice alternative to the Boost.DateTime-based one. But that doesn't make the latter useless. I think it still has its use, at least for backward compatibility and dependency reduction, like in my case. Moving to the new interface is not so complex.
Why not keep them as they are?
I could keep them, but I would prefer to reduce the code to maintain. I understand that the dual interface adds more redundancy but does it really require active maintenance? The code has been there for quite some time, it's well tested and doesn't require additional work.
Any addition code has its influence on how the library could evolve. I really would prefer to remove these interfaces for Boost 1.56. I think that 1 year and a half is enough time to move to the new interface. Best, Vicente
2012/10/13 Vicente J. Botet Escriba <vicente.botet@wanadoo.fr>:
Le 12/10/12 07:27, Akira Takahashi a écrit :
Hi, Vicente
2012/10/1 Vicente J. Botet Escriba <vicente.botet@wanadoo.fr>:
Le 30/09/12 14:19, Daniel James a écrit :
...
* [phrase library..[@/libs/thread/index.html Thread]:]
* Time related functions don't using the Boost.Chrono library, use the chrono overloads instead.
...
I could not understand this. What does mean?
Hi,
sorry for the imprecision. I meant that all the interfaces using Boost.DateTime posix_time are now deprecated. From the doc"
The time related functions introduced in Boost 1.35.0, using the Boost.DateTime library are deprecated. These include (but are not limited to):
boost::this_thread::sleep() thread::timed_join() condition_variable::timed_wait() timed_mutex::timed_lock()
"
I understand! Thanks!
On 9/30/2012 5:19 AM, Daniel James wrote:
Hello everyone,
We're coming up to the beta release, so it's time to put together the release notes (although please don't feel you need to wait for me to start). As always you can send them to me, or if you want update them yourself in subversion.
For 1.52, we'll need a big, prominent note about decltype result_of. I don't think putting it in a release note is enough. Not sure where it should go, though. Thoughts? One mitigating factor is that there are few compilers that have good enough decltype support at this point. I think clang users are the only ones that will be effected at this point. -- Eric Niebler BoostPro Computing http://www.boostpro.com
On 1 October 2012 01:59, Eric Niebler <eric@boostpro.com> wrote:
For 1.52, we'll need a big, prominent note about decltype result_of. I don't think putting it in a release note is enough. Not sure where it should go, though. Thoughts?
Something could be added to the summary, which is displayed on the home page. A news story could be created, which would be a surprise to anyone who follows that feed and thinks it only consists of release details. Could add something to the top of the left hand column of the home page (just have to edit index.html - I'd use some inline css to make it stand out, as I don't think the stylesheets contain appropriate styles). In the distribution, a note could be added to index.html in the root directory, although I don't know if anyone actually reads that. If you want to be unreasonably intrusive, a warning could be added to the header.
Sorry, Daniel, I didn't see this the first time around... On 10/1/2012 3:33 AM, Daniel James wrote:
On 1 October 2012 01:59, Eric Niebler <eric@boostpro.com> wrote:
For 1.52, we'll need a big, prominent note about decltype result_of. I don't think putting it in a release note is enough. Not sure where it should go, though. Thoughts?
Something could be added to the summary, which is displayed on the home page.
I was thinking that on boost.org, where it says: Downloads Current Release * Version 1.52.0 Details | Download | Documentation November 5th, 2012 16:05 GMT A small link in red could be added that simply says, "IMPORTANT: See here for a special note about this release." Then on a separate page, a note to this effect: A Special Note for Boost 1.52.0 and Higher ========================================== Starting in Boost 1.52.0, the boost::result_of component defaults to an implementation that uses the C++11 decltype keyword to deduce the return type of callables on compilers with strong decltype support. As boost::result_of is a key piece of library infrastructure, we at Boost have found this change to be moderately disruptive. You should be aware of the issue when making the decision to upgrade from an older version of Boost. Why the Change Was Made ----------------------- In C++11, std::result_of is required to use decltype. Boost has decided to change its implementation to minimize the differences between boost::result_of and std::result_of. Also, the use of decltype should help to improve compile times and increase the accuracy of the type computation. Who is Effected? ---------------- If you use a compiler with sufficiently bug-free decltype support (including N3276 <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3276.pdf>), then you will get the new behavior. At the time of writing (Nov 4, 2012), the only compiler in that category is clang built from trunk, but as other compilers improve, this will change. What Problems Can the Change Cause? ----------------------------------- The use of decltype in result_of can result in a different type being computed than if the now-obsolete TR1 result_of protocol. This will often be the case for incorrectly written TR1-style function objects that misreport their result types. This is unfortunately too common. But it can even happen for some correctly written function objects. Where Can I Learn More? ----------------------- Please see the documentation for boost::result_of <link> to understand the differences between TR1 result_of and decltype result_of, and to find out how you can write your code to accommodate both.
A news story could be created, which would be a surprise to anyone who follows that feed and thinks it only consists of release details.
Yes, please. With a link to the above notice.
Could add something to the top of the left hand column of the home page (just have to edit index.html - I'd use some inline css to make it stand out, as I don't think the stylesheets contain appropriate styles).
Just the red link I suggest above, near the download link. Would there also be a way to put a notice here: http://sourceforge.net/projects/boost/files/boost/1.52.0/ ? After all, people might go straight there and skip the Boost homepage. (Aside: why does it say this at sourceforge: "Looking for the latest version? Download boost_1_47_pdf.zip (31.4 MB)"? That's misleading and makes it sound like 1.47 is the latest version.)
In the distribution, a note could be added to index.html in the root directory, although I don't know if anyone actually reads that. If you want to be unreasonably intrusive, a warning could be added to the header.
I guess it's too late for that. :-/ Thanks Daniel! -- Eric Niebler BoostPro Computing http://www.boostpro.com
Eric Niebler wrote:
On 10/1/2012 3:33 AM, Daniel James wrote:
On 1 October 2012 01:59, Eric Niebler <eric@boostpro.com> wrote:
For 1.52, we'll need a big, prominent note about decltype result_of. I don't think putting it in a release note is enough. Not sure where it should go, though. Thoughts?
Something could be added to the summary, which is displayed on the home page.
I was thinking that on boost.org, where it says: [...] Who is Effected? ----------------
If you use a compiler with sufficiently bug-free decltype support (including N3276 <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3276.pdf>), then you will get the new behavior. At the time of writing (Nov 4, 2012), the only compiler in that category is clang built from trunk, but as other compilers improve, this will change.
Clang-3.1, which was released on May 22, has N3276 decltype support. Regards, Michel
Michel Morin wrote:
Who is Effected? ----------------
If you use a compiler with sufficiently bug-free decltype support (including N3276 <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3276.pdf>), then you will get the new behavior. At the time of writing (Nov 4, 2012), the only compiler in that category is clang built from trunk, but as other compilers improve, this will change.
Clang-3.1, which was released on May 22, has N3276 decltype support.
Here, I meant clang-3.1 has sufficiently bug-free decltype support and boost::result_of uses decltype-based implementation by default. Regards, Michel
On 11/5/2012 8:25 PM, Michel Morin wrote:
Michel Morin wrote:
Who is Effected? ----------------
If you use a compiler with sufficiently bug-free decltype support (including N3276 <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3276.pdf>), then you will get the new behavior. At the time of writing (Nov 4, 2012), the only compiler in that category is clang built from trunk, but as other compilers improve, this will change.
Clang-3.1, which was released on May 22, has N3276 decltype support.
Here, I meant clang-3.1 has sufficiently bug-free decltype support and boost::result_of uses decltype-based implementation by default.
Thanks for the correction. -- Eric Niebler BoostPro Computing http://www.boostpro.com
On Nov 5, 2012, at 7:58 PM, Eric Niebler <eric@boostpro.com> wrote:
Starting in Boost 1.52.0, the
s/in/with/
Why the Change Was Made -----------------------
In C++11, std::result_of is required to use decltype. Boost has decided to change its implementation to minimize the differences between boost::result_of and std::result_of.
boost::result_of has been changed to use decltype to make it more consistent with std::result_of (when sufficient compiler support is available).
Also, the use of decltype should help to improve compile times and increase the accuracy of the type computation.
Who is Effected?
s/Effected/Affected/
What Problems Can the Change Cause? -----------------------------------
The use of decltype in result_of can result in a different type being computed than if the now-obsolete TR1 result_of protocol.
s/than if the/than with the/ ___ Rob
On 11/6/2012 2:25 AM, Rob Stewart wrote:
On Nov 5, 2012, at 7:58 PM, Eric Niebler <eric@boostpro.com> wrote:
Starting in Boost 1.52.0, the
s/in/with/
Right.
Why the Change Was Made -----------------------
In C++11, std::result_of is required to use decltype. Boost has decided to change its implementation to minimize the differences between boost::result_of and std::result_of.
boost::result_of has been changed to use decltype to make it more consistent with std::result_of (when sufficient compiler support is available).
Better.
Also, the use of decltype should help to improve compile times and increase the accuracy of the type computation.
Who is Effected?
s/Effected/Affected/
Are you sure? <looks it up> Darn, you're right. I always screw this one up. Thanks for the correction.
What Problems Can the Change Cause? -----------------------------------
The use of decltype in result_of can result in a different type being computed than if the now-obsolete TR1 result_of protocol.
s/than if the/than with the/
Yup, thanks. -- Eric Niebler BoostPro Computing http://www.boostpro.com
On 6 November 2012 00:58, Eric Niebler <eric@boostpro.com> wrote:
Sorry, Daniel, I didn't see this the first time around...
On 10/1/2012 3:33 AM, Daniel James wrote:
Just the red link I suggest above, near the download link. Would there also be a way to put a notice here:
I uploaded a README file with a link.
? After all, people might go straight there and skip the Boost homepage.
(Aside: why does it say this at sourceforge: "Looking for the latest version? Download boost_1_47_pdf.zip (31.4 MB)"? That's misleading and makes it sound like 1.47 is the latest version.)
I've fixed that and added some instructions to the wiki. I think this needs to be manually updated for every release.
On 11/6/2012 4:33 AM, Daniel James wrote:
On 6 November 2012 00:58, Eric Niebler <eric@boostpro.com> wrote:
Sorry, Daniel, I didn't see this the first time around...
On 10/1/2012 3:33 AM, Daniel James wrote:
Just the red link I suggest above, near the download link.
Yup, this looks good.
Would there also be a way to put a notice here:
I uploaded a README file with a link.
Cool.
? After all, people might go straight there and skip the Boost homepage.
(Aside: why does it say this at sourceforge: "Looking for the latest version? Download boost_1_47_pdf.zip (31.4 MB)"? That's misleading and makes it sound like 1.47 is the latest version.)
I've fixed that and added some instructions to the wiki. I think this needs to be manually updated for every release.
OK, thanks Daniel! -- Eric Niebler BoostPro Computing http://www.boostpro.com
On Sun, Sep 30, 2012, at 08:19 AM, Daniel James wrote:
Hello everyone,
We're coming up to the beta release, so it's time to put together the release notes (although please don't feel you need to wait for me to start). As always you can send them to me, or if you want update them yourself in subversion.
Please add for uuid: - fixes (ticket 6118, 6788, 7375) Regards, Andy Tompkins
On Sun, Sep 30, 2012, at 08:19 AM, Daniel James wrote:
Hello everyone,
We're coming up to the beta release, so it's time to put together the release notes (although please don't feel you need to wait for me to start). As always you can send them to me, or if you want update them yourself in subversion. The files are at:
https://svn.boost.org/svn/boost/website/public_html/live/feed/history/
Please add to the list for uuid: - ticket #7128 - fixed bug in sha1.hpp for messages longer than 536,870,912 bytes Regards, Andy Tompkins
On 11 October 2012 16:35, Andy Tompkins <atompkins@fastmail.fm> wrote:
Please add to the list for uuid: - ticket #7128 - fixed bug in sha1.hpp for messages longer than 536,870,912 bytes
I've added it (and other new changes) to a separate section at the end of the release notes, so that it's clear that this is not in the beta. I'll merge them with the main release notes before the final release.
Hi, Boost.Context namespace was changed (boost::ctx -> boost::context). I think that should be described in release notes. Thanks, Kohei Takahashi (2012/09/30 21:19), Daniel James wrote:
Hello everyone,
We're coming up to the beta release, so it's time to put together the release notes (although please don't feel you need to wait for me to start). As always you can send them to me, or if you want update them yourself in subversion. The files are at:
https://svn.boost.org/svn/boost/website/public_html/live/feed/history/
The actual site won't get updated until I run the update script.
You can see the release notes so far at:
http://www.boost.org/users/history/version_1_52_0.html
As usual, they're not finished yet, and some of the links might not work as the 1.52 documentation won't be uploaded until after the beta is released.
thanks,
Daniel
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (9)
-
Akira Takahashi -
Andrey Semashev -
Andy Tompkins -
Daniel James -
Eric Niebler -
Kohei Takahashi -
Michel Morin -
Rob Stewart -
Vicente J. Botet Escriba