Boost 1.60.0 beta 1 Release Candidates available for testing
Release candidate files for 1.60.0 beta 1 are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. IMPORTANT NOTE: The files (and associated md5s) are: MD5 (boost_1_60_0_b1_rc1.7z) = ac6b2128d951ad688421fde2d878c2a7 MD5 (boost_1_60_0_b1_rc1.tar.bz2) = 2fc232f255f1ce8868315da207c05b6b MD5 (boost_1_60_0_b1_rc1.tar.gz) = d594e10f2761abaf957a67c6a223d2a4 MD5 (boost_1_60_0_b1_rc1.zip) = 16a2d512fca7995d5fa421d13f841b0f Thanks! -- The release managers
On 2015-11-09 18:52, Marshall Clow wrote:
Release candidate files for 1.60.0 beta 1 are available at http://boost.cowic.de/rc/
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
This helps ensure the candidates build OK before we push them out to SourceForge.
As you already know, Boost.Log fails to build because of unmerged commits to Boost.Spirit. I'll post a separate message. I'm seeing lots of warnings about use of deprecated std::auto_ptr in different libraries: Boost.DateTime, Boost.Locale, Boost.Signals. I've attached the list of places where these warnings occur. Other than that it compiled successfully with gcc 5.2.1 in C++11 mode.
On 2015-11-09 18:52, Marshall Clow wrote:
[snip] I'm seeing lots of warnings about use of deprecated std::auto_ptr in >different libraries: Boost.DateTime, Boost.Locale, Boost.Signals. I've attached the list of places where these warnings occur. [snip]
See... unlike Boost, most of the ordinary world still uses C++2003 and will use it for a long time especially for existing projects. Existing libraries like Boost.Locale support C++2003. std::auto_ptr is perfect way to provide ownership move semantics without rvalue reference despite the fact some may abuse it. So when you do need have to have move semantics, auto_ptr needs to be there. Using #ifdef USING_CPP11 std::unique_ptr<foo> bar(); #else std::auto_ptr<foo> bar(); #endif Both makes horrible code and adds huge binary compatibility issues that Boost has enough of them. IMHO deprecation of std::auto_ptr was one of the biggest design mistakes of C++11 because it does not allow writing code that supports both C++03 and C++11. std::auto_ptr isn't broken the way gets is, it is actually very good class with its limitations. So Boost.Locale would keep using auto_ptr until another "smart guy" in C++1X/2X committee would decide to break more good things and remove it entirely so there would be no choice. Artyom Beilis
On 2015-11-10 15:51, Artyom Beilis wrote:
On 2015-11-09 18:52, Marshall Clow wrote:
[snip] I'm seeing lots of warnings about use of deprecated std::auto_ptr in >different libraries: Boost.DateTime, Boost.Locale, Boost.Signals. I've attached the list of places where these warnings occur. [snip]
See... unlike Boost, most of the ordinary world still uses C++2003 and will use it for a long time especially for existing projects.
Existing libraries like Boost.Locale support C++2003.
std::auto_ptr is perfect way to provide ownership move semantics without rvalue reference despite the fact some may abuse it.
I wouldn't call it perfect. In the lack of rvalue references I would have preferred an explicit method to return a proxy that acts like rvalue reference. But that's offtopic. Would you consider porting Boost.Locale to boost::movelib::unique_ptr from Boost.Move? Note that you will have to switch at some point as MSVC developers are planning to remove auto_ptr from the standard library at some point.
On 10-Nov-15 4:08 PM, Andrey Semashev wrote:
On 2015-11-10 15:51, Artyom Beilis wrote:
On 2015-11-09 18:52, Marshall Clow wrote:
[snip] I'm seeing lots of warnings about use of deprecated std::auto_ptr in >different libraries: Boost.DateTime, Boost.Locale, Boost.Signals. I've attached the list of places where these warnings occur. [snip]
See... unlike Boost, most of the ordinary world still uses C++2003 and will use it for a long time especially for existing projects.
Existing libraries like Boost.Locale support C++2003.
std::auto_ptr is perfect way to provide ownership move semantics without rvalue reference despite the fact some may abuse it.
I wouldn't call it perfect. In the lack of rvalue references I would have preferred an explicit method to return a proxy that acts like rvalue reference. But that's offtopic.
Would you consider porting Boost.Locale to boost::movelib::unique_ptr from Boost.Move?
Note that you will have to switch at some point as MSVC developers are planning to remove auto_ptr from the standard library at some point.
Do you have a link saying so? That's quite unfortunate stance, indeed. -- Vladimir Prus http://vladimirprus.com
On 10 November 2015 at 14:31, Vladimir Prus <vladimir.prus@gmail.com> wrote:
On 10-Nov-15 4:08 PM, Andrey Semashev wrote:
On 2015-11-10 15:51, Artyom Beilis wrote:
On 2015-11-09 18:52, Marshall Clow wrote:
[snip] I'm seeing lots of warnings about use of deprecated std::auto_ptr in
different libraries: Boost.DateTime, Boost.Locale, Boost.Signals. I've attached the list of places where these warnings occur. [snip]
See... unlike Boost, most of the ordinary world still uses C++2003 and will use it for a long time especially for existing projects.
Existing libraries like Boost.Locale support C++2003.
std::auto_ptr is perfect way to provide ownership move semantics without rvalue reference despite the fact some may abuse it.
I wouldn't call it perfect. In the lack of rvalue references I would have preferred an explicit method to return a proxy that acts like rvalue reference. But that's offtopic.
Would you consider porting Boost.Locale to boost::movelib::unique_ptr from Boost.Move?
Note that you will have to switch at some point as MSVC developers are planning to remove auto_ptr from the standard library at some point.
Do you have a link saying so? That's quite unfortunate stance, indeed.
I think, this is the relevant announcement: http://blogs.msdn.com/b/vcblog/archive/2015/04/29/c-11-14-17-features-in-vs-... """ [2015 opt-in] Available in VS 2015 RC, but guarded by a macro. By default, we provide auto_ptr/etc. If you define _HAS_AUTO_PTR_ETC to 0 project-wide (which you should do via the command line or project file, not via #define), then we won't provide auto_ptr/etc. This opt-in behavior will remain unchanged in 2015 RTM. In the next major version, I'm planning to make this opt-out, and in the major version after that, I'm planning to eliminate auto_ptr/etc. entirely. Now would be a good time to start migrating your code. (I've already informed Boost's maintainers.) """ BTW, I have been asking about _HAS_AUTO_PTR_ETC support too http://lists.boost.org/boost-users/2015/09/84965.php Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
On 2015-11-10 16:54, Mateusz Loskot wrote:
On 10 November 2015 at 14:31, Vladimir Prus <vladimir.prus@gmail.com> wrote:
On 10-Nov-15 4:08 PM, Andrey Semashev wrote:
On 2015-11-10 15:51, Artyom Beilis wrote:
On 2015-11-09 18:52, Marshall Clow wrote:
[snip] I'm seeing lots of warnings about use of deprecated std::auto_ptr in
different libraries: Boost.DateTime, Boost.Locale, Boost.Signals. I've attached the list of places where these warnings occur. [snip]
See... unlike Boost, most of the ordinary world still uses C++2003 and will use it for a long time especially for existing projects.
Existing libraries like Boost.Locale support C++2003.
std::auto_ptr is perfect way to provide ownership move semantics without rvalue reference despite the fact some may abuse it.
I wouldn't call it perfect. In the lack of rvalue references I would have preferred an explicit method to return a proxy that acts like rvalue reference. But that's offtopic.
Would you consider porting Boost.Locale to boost::movelib::unique_ptr from Boost.Move?
Note that you will have to switch at some point as MSVC developers are planning to remove auto_ptr from the standard library at some point.
Do you have a link saying so? That's quite unfortunate stance, indeed.
I think, this is the relevant announcement:
http://blogs.msdn.com/b/vcblog/archive/2015/04/29/c-11-14-17-features-in-vs-...
""" [2015 opt-in] Available in VS 2015 RC, but guarded by a macro. By default, we provide auto_ptr/etc. If you define _HAS_AUTO_PTR_ETC to 0 project-wide (which you should do via the command line or project file, not via #define), then we won't provide auto_ptr/etc.
This opt-in behavior will remain unchanged in 2015 RTM. In the next major version, I'm planning to make this opt-out, and in the major version after that, I'm planning to eliminate auto_ptr/etc. entirely. Now would be a good time to start migrating your code. (I've already informed Boost's maintainers.) """
BTW, I have been asking about _HAS_AUTO_PTR_ETC support too http://lists.boost.org/boost-users/2015/09/84965.php
There was also this discussion here: http://thread.gmane.org/gmane.comp.lib.boost.devel/258501
[Mateusz Loskot]
I think, this is the relevant announcement: http://blogs.msdn.com/b/vcblog/archive/2015/04/29/c-11-14-17-features-in-vs-...
BTW, I have been asking about _HAS_AUTO_PTR_ETC support too http://lists.boost.org/boost-users/2015/09/84965.php
[Andrey Semashev]
There was also this discussion here: http://thread.gmane.org/gmane.comp.lib.boost.devel/258501
I still want to make this change for the next major version of VC, and having Boost migrated will help with that (as we've harnessed Boost in our tests). Note that unary_function/etc. also need to be migrated, as _HAS_AUTO_PTR_ETC=0 controls everything. (And yes, we're aware of some MS libraries that need to respect the option; PPL is being fixed, and I know my collection.h is also using unary_function.) Thanks, STL
Note that you will have to switch at some point as MSVC developers are
planning to remove auto_ptr from the standard library at some point.
Do you have a link saying so? That's quite unfortunate stance, indeed.
I think, this is the relevant announcement:
http://blogs.msdn.com/b/vcblog/archive/2015/04/29/c-11-14-17-features-in-vs-...
"""
Does it disturb only me? http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4190.htm I don't see ANY reason whatsoever to break existing code unless the use of some code opens some critical security bugs like gets() for example. Telling the entire C++ community you don't have X any more because you have Y which is better and break millions lines of code just because. I think this proposal is totally disconnected from real world. I'd recommend anybody who actually has access to standard committee scrap this proposal and kill it without mercy. There is no reason to break unbroken code. Artyom
On Tue, Nov 10, 2015 at 8:47 AM, Artyom Beilis <artyomtnk@yahoo.com> wrote:
I don't see ANY reason whatsoever to break existing code unless the use of some code opens some critical security bugs like gets() for example.
Telling the entire C++ community you don't have X any more because you have Y which is better and break millions lines of code just because.
I think this proposal is totally disconnected from real world.
I'd recommend anybody who actually has access to standard committee scrap this proposal and kill it without mercy.
There is no reason to break unbroken code.
There's a bit more to it than "now we have unique_ptr": http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html#20.4.5%20...
From above:
"auto_ptr moves from lvalues using copy syntax and is thus fundamentally unsafe." I agree with the author of that paper that the use of auto_ptr *is* broken in the general case, and so it should be deprecated and removed. Zach
On 11/11/2015 03:03 AM, Zach Laine wrote:
On Tue, Nov 10, 2015 at 8:47 AM, Artyom Beilis <artyomtnk@yahoo.com> wrote:
I don't see ANY reason whatsoever to break existing code unless the use of some code opens some critical security bugs like gets() for example. ... I think this proposal is totally disconnected from real world. ... ... I agree with the author of that paper that the use of auto_ptr *is* broken in the general case, and so it should be deprecated and removed.
Deprecating and removing are not quite the same with very different outcomes to the end-user. No matter how much one likes C++11 and how much auto_prt is "broken" it appears outright irresponsible removing such an important and well-entrenched component with huge impact onto the end-user code base. The concern expressed by Artyom is well-justified. There cannot be ifs and buts about it.
On 11/10/2015 6:09 PM, Vladimir Batov wrote:
On 11/11/2015 03:03 AM, Zach Laine wrote:
On Tue, Nov 10, 2015 at 8:47 AM, Artyom Beilis <artyomtnk@yahoo.com> wrote:
I don't see ANY reason whatsoever to break existing code unless the use of some code opens some critical security bugs like gets() for example. ... I think this proposal is totally disconnected from real world. ... ... I agree with the author of that paper that the use of auto_ptr *is* broken in the general case, and so it should be deprecated and removed.
Deprecating and removing are not quite the same with very different outcomes to the end-user. No matter how much one likes C++11 and how much auto_prt is "broken" it appears outright irresponsible removing such an important and well-entrenched component with huge impact onto the end-user code base. The concern expressed by Artyom is well-justified. There cannot be ifs and buts about it.
I believe one is allowed to say that Y does everything that X does and is better and therefore X will be removed at some time in the future. If one cannot say that then computer programming will never advance to the use of better programming idioms. I don't believe that one must carry the baggage of X forever because some programmers want to use X in perpetuity. This is a general reflection and is not a specific argument for std::unique_ptr versus std::auto_ptr. However technically std::unique_ptr appears to me to be a superior programming idiom than std::auto_ptr and while I am not going to argue over a date in which std::auto_ptr should no longer be part of the C++ standard library, it seems inevitable to me that at some time in the future it would be removed from the C++ standard library.
On 11/11/2015 12:17 PM, Edward Diener wrote:
On 11/10/2015 6:09 PM, Vladimir Batov wrote:
On 11/11/2015 03:03 AM, Zach Laine wrote:
On Tue, Nov 10, 2015 at 8:47 AM, Artyom Beilis <artyomtnk@yahoo.com> wrote:
I don't see ANY reason whatsoever to break existing code unless the use of some code opens some critical security bugs like gets() for example. ... I think this proposal is totally disconnected from real world. ... ... I agree with the author of that paper that the use of auto_ptr *is* broken in the general case, and so it should be deprecated and removed.
Deprecating and removing are not quite the same with very different outcomes to the end-user. No matter how much one likes C++11 and how much auto_prt is "broken" it appears outright irresponsible removing such an important and well-entrenched component with huge impact onto the end-user code base. The concern expressed by Artyom is well-justified. There cannot be ifs and buts about it.
I believe one is allowed to say that Y does everything that X does and is better and therefore X will be removed at some time in the future. If one cannot say that then computer programming will never advance to the use of better programming idioms. I don't believe that one must carry the baggage of X forever because some programmers want to use X in perpetuity.
This is a general reflection and is not a specific argument for std::unique_ptr versus std::auto_ptr. However technically std::unique_ptr appears to me to be a superior programming idiom than std::auto_ptr and while I am not going to argue over a date in which std::auto_ptr should no longer be part of the C++ standard library, it seems inevitable to me that at some time in the future it would be removed from the C++ standard library.
Edward, I was not implying that "one is disallowed to say..." or that "std::unique_ptr is inferior...". I apologize if I inadvertently created that impression. My concern was about the ease "deprecated and removed" appear together. For example, gets() was deprecated in C99. Removed in the C2011 standard. Still available in GCC implementation. Applying the deprecated-to-removed transition in just a few years seems hasty. That impression comes from mentioned (http://blogs.msdn.com/b/vcblog/archive/2015/04/29/c-11-14-17-features-in-vs-...) indicating that the second "major version" after VS2015 (2019?) auto_ptr won't be available. If I understood it correctly, I found it concerning... but I feel common sense will prevail. :-)
On 10 November 2015 at 20:17, Vladimir Batov < Vladimir.Batov@constrainttec.com> wrote:
\My concern was about the ease "deprecated and removed" appear together. For example, gets() was deprecated in C99. Removed in the C2011 standard.
How many revs of the C standard are there between deprecation of gets() and removal? It is less than *one*, because gets() was not deprecated when C99 was first published. It will have been two revs of the C++ standard between deprecation and removal of auto_ptr, and it has been well known that auto_ptr was going to be deprecated in C++0x years before that became C++11. -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
----- Original Message -----
From: Nevin Liber <nevin@eviloverlord.com>
\My concern was about the ease "deprecated and removed" appear together. For example, gets() was deprecated in C99. Removed in the C2011 standard.
How many revs of the C standard are there between deprecation of gets() and removal? It is less than *one*, because gets() was not deprecated when C99 was first published.
Don't even try to compare gets with auto_ptr... One is HUGE security hole and another one some stuff that should be used carefully, it isn't more dangerous that strncpy and far less dangerous that sprintf that goes nowhere.
It will have been two revs of the C++ standard between deprecation and removal of auto_ptr, and it has been well known that auto_ptr was going to be deprecated in C++0x years before that became C++11. --
When C++11 was released and how well it is supported by now? Ok when I started for example Boost.Locale few years ago No major widely available compiler had provided unique_ptr. I'm using Ubuntu LTS 14.4 (a distro one year old with long support) and gcc-4.8 does not support regular expressions yet! At another place I'm using up-to-date RHEL 6.x... it comes with gcc-4.4 and guess what is C++11 support level is there? And yet no-major compiler (besides MSVC 2015 or something like) really support C++11 char16_t/char32_t (I mean all stuff including facets) There is HUGE difference between the standard release time and what world actually uses... MSVC does not even support properly C99 yet and it was released more than a decade ago and it is C much simpler language. So it would take a very long time until industry will move to C++11 and until all major main-stream compilers would have decent C++11 support. So removing very useful stuff that isn't really that bad and that is used in library interfaces (so its removal breaks APIs) it what is what Linus Torvalds would say "brain damaged" decision. Artyom Beilis
On 11 November 2015 at 11:05, Artyom Beilis <artyomtnk@yahoo.com> wrote:
I'm using Ubuntu LTS 14.4 (a distro one year old with long support) and gcc-4.8 does not support regular expressions yet!
If you are using a compiler from two years ago, why do you care? Older compilers and their corresponding libraries will have auto_ptr.
At another place I'm using up-to-date RHEL 6.x... it comes with gcc-4.4 and guess what is C++11 support level is there?
If you are using a compiler from six years ago, why do you care? Older compilers and their corresponding libraries will have auto_ptr.
So removing very useful stuff that isn't really that bad and that is used in library interfaces (so its removal breaks APIs) it what is what Linus Torvalds would say "brain damaged" decision.
Linus is, of course, entitled to his opinion. -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
On 2015-11-11 20:05, Artyom Beilis wrote:
Ok when I started for example Boost.Locale few years ago No major widely available compiler had provided unique_ptr.
I'm using Ubuntu LTS 14.4 (a distro one year old with long support) and gcc-4.8 does not support regular expressions yet!
At another place I'm using up-to-date RHEL 6.x... it comes with gcc-4.4 and guess what is C++11 support level is there?
For the record, gcc 4.4, let alone 4.8, do provide unique_ptr. I've been using unique_ptr for a few years now (since circa 2011-2012, I think). I've been using gcc 4.4 in our production projects in C++0x mode for a few years until we upgraded to 4.7. Yes, 4.4 is buggy in many ways, but it still supports the fundamental C++11 features, including rvalue references (early version of) and unique_ptr. IMO it is fair to say that most currently wide spread C++ compilers do support C++11 to some degree.
There is HUGE difference between the standard release time and what world actually uses... MSVC does not even support properly C99 yet and it was released more than a decade ago and it is C much simpler language.
MS and C is a whole different story. MSVC never supported C properly, and I don't think it ever will. They do try to support C++ better, at least feature-wise, at least in parts that are not C.
On Wed, Nov 11, 2015 at 05:05:41PM +0000, Artyom Beilis wrote:
Don't even try to compare gets with auto_ptr... One is HUGE security hole and another one some stuff that should be used carefully, it isn't more dangerous that strncpy and far less dangerous that sprintf that goes nowhere.
It will have been two revs of the C++ standard between deprecation and removal of auto_ptr, and it has been well known that auto_ptr was going to be deprecated in C++0x years before that became C++11. --
When C++11 was released and how well it is supported by now?
Ok when I started for example Boost.Locale few years ago No major widely available compiler had provided unique_ptr.
I'm using Ubuntu LTS 14.4 (a distro one year old with long support) and gcc-4.8 does not support regular expressions yet!
At another place I'm using up-to-date RHEL 6.x... it comes with gcc-4.4 and guess what is C++11 support level is there?
And yet no-major compiler (besides MSVC 2015 or something like) really support C++11 char16_t/char32_t (I mean all stuff including facets)
There is HUGE difference between the standard release time and what world actually uses... MSVC does not even support properly C99 yet and it was released more than a decade ago and it is C much simpler language.
So it would take a very long time until industry will move to C++11 and until all major main-stream compilers would have decent C++11 support.
Hi Artyom, While I appreciate your point of view, I believe it is too focused on your own limited perspective. For example, Apple, Google, and Facebook are all using C++11 extensively. Here in Silicon Valley, the startup ecosystem is using c++11/c++14 almost exclusively. They are using clang/llvm mostly, while quite a few others are using the latest g++, which is currently gcc-5.x. The vast majority of new jobs are created by the startup ecosystem. (Future boost releases should be mindful of the tool chains being used to create most of the new jobs.)
So removing very useful stuff that isn't really that bad and that is used in library interfaces (so its removal breaks APIs) it what is what Linus Torvalds would say "brain damaged" decision.
I worked with the linux kernel for quite a few years, before focusing on C++11/14 and applications. It was a long standing policy of the kernel community to break APIs when they were getting in the way of progress. And they did break APIs quite a few times. Linus Torvalds says a lot of things. I don't doubt your quote, but you can find many quotes of Linus, where he was advocating breaking APIs. I don't believe injecting Torvald's quotes into this discussion adds any value. Karen -- Karen Shaeffer Be aware: If you see an obstacle in your path, Neuralscape Services that obstacle is your path. Zen proverb
Hi Artyom,
While I appreciate your point of view, I believe it is too focused on your own limited perspective. For example, Apple, Google, and Facebook are all using C++11 extensively.
Here in Silicon Valley, the startup ecosystem is using c++11/c++14 almost exclusively. They are using clang/llvm mostly, while quite a few others are using the latest g++, which is currently gcc-5.x. The vast majority of new jobs are created by the startup ecosystem. (Future boost releases should be mindful of the tool chains being used to create most of the new jobs.)
Yes... for every new project or actively developed one C++11 is great. But there are two areas where it isn't (a) Existing projects that need to be maintained in new environment (b) Libraries that need to support C++03 as they are used in wide range of environments (like Boost for example) and should provide same API.
I worked with the linux kernel for quite a few years, before focusing on C++11/14 and applications. It was a long standing policy of the kernel community to break APIs when they were getting in the way of progress.
Yes... but that is why if you want your code to work in Kernel you should push it to kernel and not keep to yourself. Kernel API is internal API of project. On the other hand user level API (i.e. system calls) are almost NEVER broken. I suggest if you refer to Linus and breaking API take a look on Red Hat and memcpy... when glibc decided to reverse copy direction and Flash stopped working. Linus was very critical of breaking stuff in User space. auto_ptr is user space. It isn't internal implementation of things it is public API and for kernel it never breaks. It is really frustrating the ease the API breaks effecting entire industry. Artyom
Howard runs and gets another bowl of popcorn!...
On Wed, Nov 11, 2015 at 07:08:38PM +0000, Artyom Beilis wrote:
Hi Artyom,
While I appreciate your point of view, I believe it is too focused on your own limited perspective. For example, Apple, Google, and Facebook are all using C++11 extensively.
Here in Silicon Valley, the startup ecosystem is using c++11/c++14 almost exclusively. They are using clang/llvm mostly, while quite a few others are using the latest g++, which is currently gcc-5.x. The vast majority of new jobs are created by the startup ecosystem. (Future boost releases should be mindful of the tool chains being used to create most of the new jobs.)
Yes... for every new project or actively developed one C++11 is great.
But there are two areas where it isn't
(a) Existing projects that need to be maintained in new environment (b) Libraries that need to support C++03 as they are used in wide range of environments (like Boost for example) and should provide same API.
Hi Artyom, Well put. Let's say your project upgrades to g++-5.2. I've never verified this, but isn't it true that you could continue to use std::auto_ptr by compiling with the -std=c++03 flag? In the context of libraries, it is an interesting issue. Every library development group must deal with this issue. Boost is a good example. I believe implementing a clean c++14 version and maintaining the existing version for backwards compatibility is the ideal solution, because it enables the new projects to see boost as viable in the long run while continuing to support long standing users associated with legacy projects that often have very long lifetimes. I realize the ideal isn't practical for many libraries.
I worked with the linux kernel for quite a few years, before focusing on C++11/14 and applications. It was a long standing policy of the kernel community to break APIs when they were getting in the way of progress.
Yes... but that is why if you want your code to work in Kernel you should push it to kernel and not keep to yourself. Kernel API is internal API of project.
On the other hand user level API (i.e. system calls) are almost NEVER broken.
Agreed. I will say the linux kernel software project is huge by any standards with a very large set of internal APIs that are used by many other subsystems. And when they break those internal APIs, folks can become engaged in heated discussions. But the policy was overriding, and progress marched on. Thank you for your comments. I enjoyed reading them. Karen -- Karen Shaeffer Be aware: If you see an obstacle in your path, Neuralscape Services that obstacle is your path. Zen proverb
On 11 November 2015 at 19:46, Karen Shaeffer wrote:
Well put. Let's say your project upgrades to g++-5.2. I've never verified this, but isn't it true that you could continue to use std::auto_ptr by compiling with the -std=c++03 flag?
Yes. Or -std=c++11. Or -std=c++14.
On Wed, Nov 11, 2015 at 1:10 PM, Jonathan Wakely <jwakely.boost@kayari.org> wrote:
On 11 November 2015 at 19:46, Karen Shaeffer wrote:
Well put. Let's say your project upgrades to g++-5.2. I've never verified this, but isn't it true that you could continue to use std::auto_ptr by compiling with the -std=c++03 flag?
Yes. Or -std=c++11. Or -std=c++14.
That would also be true for libc++. To do otherwise, we wouldn't be able to say that we're "c++11 compliant". If you build with -std=c++11, you should get a C++11 standard library. (modulo bug fixes) -- Marshall
Jonathan Wakely wrote:
On 11 November 2015 at 19:46, Karen Shaeffer wrote:
Well put. Let's say your project upgrades to g++-5.2. I've never verified this, but isn't it true that you could continue to use std::auto_ptr by compiling with the -std=c++03 flag?
Yes. Or -std=c++11. Or -std=c++14.
We (Boost developers) don't control with what flags our users compile our libraries. Although, to be honest, I kind of prefer auto_ptr not being there at all rather than being there and generating tons of deprecation warnings.
On 11/11/2015 20:08, Artyom Beilis wrote:
Hi Artyom,
While I appreciate your point of view, I believe it is too focused on your own limited perspective. For example, Apple, Google, and Facebook are all using C++11 extensively.
Here in Silicon Valley, the startup ecosystem is using c++11/c++14 almost exclusively. They are using clang/llvm mostly, while quite a few others are using the latest g++, which is currently gcc-5.x. The vast majority of new jobs are created by the startup ecosystem. (Future boost releases should be mindful of the tool chains being used to create most of the new jobs.)
Yes... for every new project or actively developed one C++11 is great.
But there are two areas where it isn't
(a) Existing projects that need to be maintained in new environment (b) Libraries that need to support C++03 as they are used in wide range of environments (like Boost for example) and should provide same API.
For those like me that work in industrial environments, when you need to give support for 30 years, C++11 won't be an option in several years. Not to mention safety-related qualified toolchains which are really conservative. Silicon Valley is not the place were most C++ programmers work. The only thing we really miss is move semantics, we can live without lambdas, uniform initialization, etc. custom libraries can fill missing c++11 std library features. In any case Artyom, I designed boost.unique_ptr's C++03 mode to be as lightweight as possible. Please take a look at it, it might work for you as a long-term solution. Boost.Container also supports emulated move semantics and boost.unique_ptr, so you might have a good ecosystem to obtain more safety in C++03 compilers in a forward-compatible way. Best, Ion
On 11/11/2015 06:05 PM, Artyom Beilis wrote:
Ok when I started for example Boost.Locale few years ago No major widely available compiler had provided unique_ptr.
I'm using Ubuntu LTS 14.4 (a distro one year old with long support) and gcc-4.8 does not support regular expressions yet!
Both unique_ptr and regexp are available in Boost, so I am not sure what the relevance of these observations are on a Boost mailing-list.
So removing very useful stuff that isn't really that bad and that is used in library interfaces (so its removal breaks APIs) it what is what Linus Torvalds would say "brain damaged" decision.
Given that this is a Boost mailing-list, I am struggling to understand were you are going with this discussion. If you wish to object to the removal of auto_ptr, a better venue is the std-proposals mailing-list. If you wish to add a boost::auto_ptr to replace the disappearing std::auto_ptr then that would be on-topic here. Can you clarify your intentions please?
Given that this is a Boost mailing-list, I am struggling to understand were you are going with this discussion.
If you wish to object to the removal of auto_ptr, a better venue is the std-proposals mailing-list.
Excellent question... Boost has impact. Some committee members read and write there, standard library developers read and write there. Boost is case of a widely used library that works from gcc-3.4 to gcc-6 from MSVC-2005 to 2015 and even more. The perspective of library developers who design a library and API for very-very-wide range of platforms and compilers think differently. Library developers do not have a lechery to say we have new good stuff that make things better lets use it in our *API*... because ooooops - 90% of the real world can't use because they don't use bleeding edge stuff. I hope such a discussion would give a different perspective, provide more awareness to developers and hopefully effect some decision makers If you think that this discussion should be canceled... no problem. Artyom
And yet no-major compiler (besides MSVC 2015 or something like) really support C++11 char16_t/char32_t (I mean all stuff including facets)
What are you smoking?
A very good stuff ;) On more serious note... try to run std::basic_ostringstream<char16_t> ss; ss<<1234.23; std::cout << ss.str().size() << std::endl; You'll see that latest gcc with latest libstdc++ and latest clang with latest libc++ would give you 0 - .i.e no output generated (tested few weeks ago) Only latest MSVC does the job. Having char16_t and char32_t does not mean that they are actually useful. Artyom
On 11 November 2015 at 01:17, Edward Diener wrote:
I believe one is allowed to say that Y does everything that X does and is better and therefore X will be removed at some time in the future. If one cannot say that then computer programming will never advance to the use of better programming idioms. I don't believe that one must carry the baggage of X forever because some programmers want to use X in perpetuity.
Yes, well said.
This is a general reflection and is not a specific argument for std::unique_ptr versus std::auto_ptr. However technically std::unique_ptr appears to me to be a superior programming idiom than std::auto_ptr and while I am not going to argue over a date in which std::auto_ptr should no longer be part of the C++ standard library, it seems inevitable to me that at some time in the future it would be removed from the C++ standard library.
It has already been removed from the current C++ working paper (what will be C++17). That doesn't mean implementors have to stop providing it, it only means it is no longer defined by the standard. Supporting older versions of the standard and users who mix old and new code is the implementors job, it doesn't need to be supported by the C++17 standard. The C++17 standard defines C++17, not C++-a-bit-of-this-and-a-bit-of-that. If you have important reasons to keep using std::auto_ptr in modern code then convince your standard library vendor to keep providing it. (Although in this case I think using Boost's own unique_ptr makes far more sense than throwing a hissy fit because a widely-misused class has been removed. The C++ committee regularly gets criticised for too much backwards compatibility, so while one angry person on the internet is annoyed the first time a deprecated feature is actually removed there are probably far more people saying "at last!!!").
On 11 November 2015 at 15:08, Jonathan Wakely <jwakely.boost@kayari.org> wrote:
That doesn't mean implementors have to stop providing it, it only means it is no longer defined by the standard.
I'm not convinced they can. Quoting [namespace.std]: "The behavior of a C++ program is undefined if it adds declarations or definitions to namespace std or to a namespace within namespace std unless otherwise specified." And there is no wording in diff.cpp14.depr] which otherwise specifies it. Or does this fall under it being UB, so vendors can define the behavior however they like? (Seems kind of wrong because we have a UB detector [aka constexpr] with defined semantics and are looking to define more of what happens with UB [contracts], but I digress...) -- Nevin ":-)" Liber <mailto:nevin@cplusplusguy.com <nevin@eviloverlord.com>> +1-847-691-1404
On 11 November 2015 at 22:42, Nevin Liber wrote:
On 11 November 2015 at 15:08, Jonathan Wakely <jwakely.boost@kayari.org> wrote:
That doesn't mean implementors have to stop providing it, it only means it is no longer defined by the standard.
I'm not convinced they can.
Quoting [namespace.std]: "The behavior of a C++ program is undefined if it adds declarations or definitions to namespace std or to a namespace within namespace std unless otherwise specified."
And there is no wording in diff.cpp14.depr] which otherwise specifies it.
Or does this fall under it being UB, so vendors can define the behavior however they like? (Seems kind of wrong because we have a UB detector [aka constexpr] with defined semantics and are looking to define more of what happens with UB [contracts], but I digress...)
P005R2 proposes a new clause that allows implementations to keep using names that used to be in the standard: 17.6.4.3.x Zombie names [zombie.names] In namespace std, the following names are reserved for previous standardization: auto_ptr, bind1st, bind2nd, binder1st, binder2nd, mem_fun, mem_fun_ref, mem_fun_t,mem_fun1_t, mem_fun_ref_t, mem_fun1_ref_t, const_mem_fun_t, const_mem_fun1_t, const_mem_fun_ref_t, const_mem_fun1_ref_t, not1, not2, unary_negate,binary_negate, ptr_fun, pointer_to_unary_function, pointer_to_binary_function, random_shuffle, unary_function, and binary_function. It is unspecified whether function objects in the C++ standard library additionally provide the following typedefs: result_type, argument_type, first_argument_type, andsecond_argument_type.
On 11 November 2015 at 22:55, Jonathan Wakely wrote:
On 11 November 2015 at 22:42, Nevin Liber wrote:
On 11 November 2015 at 15:08, Jonathan Wakely <jwakely.boost@kayari.org> wrote:
That doesn't mean implementors have to stop providing it, it only means it is no longer defined by the standard.
I'm not convinced they can.
Quoting [namespace.std]: "The behavior of a C++ program is undefined if it adds declarations or definitions to namespace std or to a namespace within namespace std unless otherwise specified."
In any case, that is a restriction on *users* not implementations. The thing that prevents implementations providing it is that "auto_ptr" is not a reserved name, so users could define a macro with that name, but that's disallowed by [zombie.names] which says that std::auto_ptr is a reserved name, even though the standard doesn't define anything with that name.
From: Andrey Semashev <andrey.semashev@gmail.com>
[snip] I'm seeing lots of warnings about use of deprecated std::auto_ptr [snip]
... See... unlike Boost, most of the ordinary world still uses C++2003 and will
I wouldn't call it perfect. In the lack of rvalue references I would have preferred an explicit method to return a proxy that acts like rvalue reference. But that's offtopic.
The point is that semantics of auto_ptr makes it clear who owns what, it works well for more than a decade and of course well known to users.
Would you consider porting Boost.Locale to boost::movelib::unique_ptr from Boost.Move?
Note that you will have to switch at some point as MSVC developers are
planning to remove auto_ptr from the standard library at some point.
To be honest I'd prefer something simple and straight forward over rvalue simulation library. I'd rather grap an implementation of auto_ptr directly to Boost.Locale. To keep simple and clear. I just what to note - Boost.Locale can be compiled in C++11 mode and used in C++03 mode - without breaking binary compatibility - few libraries do it but I'd rather want to keep it that way. Artyom
On 2015-11-10 16:46, Artyom Beilis wrote:
From: Andrey Semashev <andrey.semashev@gmail.com>
Would you consider porting Boost.Locale to boost::movelib::unique_ptr from Boost.Move?
Note that you will have to switch at some point as MSVC developers are planning to remove auto_ptr from the standard library at some point.
To be honest I'd prefer something simple and straight forward over rvalue simulation library. I'd rather grap an implementation of auto_ptr directly to Boost.Locale.
To keep simple and clear.
The choice is yours, of course. Just wanted to say that such practice doesn't scale and really doesn't help integrating with your library. I'd rather prefer we have a common equivalent of unique_ptr throughout Boost.
I just what to note - Boost.Locale can be compiled in C++11 mode and used in C++03 mode - without breaking binary compatibility - few libraries do it but I'd rather want to keep it that way.
I think this is a worthwhile goal but it can be achieved while still using unique_ptr when possible. For example, the ABI could contain raw pointers or references and thin inline wrappers implementing the API could wrap those pointers into what is a natural wrapper for the application.
On 11/11/2015 02:46, Artyom Beilis wrote:
The point is that semantics of auto_ptr makes it clear who owns what, it works well for more than a decade and of course well known to users.
Anecdotal evidence suggests that many users of auto_ptr did not find its behaviour sufficiently well known to avoid using it in buggy ways. The problem is that most of the ways to use it "wrong" arise out of default compiler behaviour that can kick in with seemingly innocent code when you simply forget to do certain things (like disable or reimplement the copy constructor). Whereas unique_ptr will give you compiler errors until you fix the code, making it inherently safer, if at times a little more annoying. Having said that, I do currently use auto_ptr (in a safe way) in some code of my own (since it came from C++03 roots, and is now dual compiled), and I'm a little sad about the decision to remove it entirely in the near future. Deprecation makes sense though, and in my case at least it's relatively simple to replace with unique_ptr. I suspect though that if it's not removed at some point, then people will continue using it incorrectly; this was probably a factor in the committee's decision to remove it rather than merely leaving it deprecated, and similarly for MS following suit.
Applying the deprecated-to-removed transition in just a few years seems hasty. That impression comes from mentioned (http://blogs.msdn.com/b/vcblog/archive/2015/04/29/c-11-14-17-features-in-vs-...) indicating that the second "major version" after VS2015 (2019?) auto_ptr won't be available. If I understood it correctly, I found it concerning... but I feel common sense will prevail. :)
So, seven years is hasty? :)
[Gavin Lambert]
I suspect though that if it's not removed at some point, then people will continue using it incorrectly; this was probably a factor in the committee's decision to remove it rather than merely leaving it deprecated, and similarly for MS following suit.
Yes. Regardless of how individual Boost developers may feel about the issue: 1. auto_ptr/etc. have been removed from the C++17 Working Paper. It's done, they're gone, and they're not coming back. (They were deprecated in C++11/14, so National Bodies can't object - that is the very meaning of deprecation.) 2. Implementations are migrating - GCC is emitting deprecation warnings, and VC is moving towards outright removal. 3. On the other side, Boost should respect the wishes of programmer-users who wish to migrate early (e.g. compiling with /D_HAS_AUTO_PTR_ETC=0). Therefore, Boost should stop using auto_ptr/etc. The mechanism for doing so is up to you (conditioning on toolset version is probably the way to go, possibly with escape hatches). Supporting leading-edge toolsets in this manner should be no different than supporting the old toolsets that Boost already goes to great effort for. Stephan T. Lavavej Senior Developer - Visual C++ Libraries
On Tue, Nov 10, 2015 at 4:51 AM, Artyom Beilis <artyomtnk@yahoo.com> wrote:
On 2015-11-09 18:52, Marshall Clow wrote:
[snip] I'm seeing lots of warnings about use of deprecated std::auto_ptr in different libraries: Boost.DateTime, Boost.Locale, Boost.Signals. I've attached the list of places where these warnings occur. [snip]
I did not write that. -- Marshall
From: Marshall Clow <mclow.lists@gmail.com>
On 2015-11-09 18:52, Marshall Clow wrote: (<--- incorrect) [snip] I'm seeing lots of warnings about use of deprecated std::auto_ptr ... [snip]
I did not write that.
-- Marshall
I'm sorry for the wrong quote title... Indeed the quote is of Andrey Semashev Artyom Beilis
On 09/11/15 18:52, Marshall Clow wrote:
Release candidate files for 1.60.0 beta 1 are available at http://boost.cowic.de/rc/
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
This helps ensure the candidates build OK before we push them out to SourceForge.
IMPORTANT NOTE:
The files (and associated md5s) are: MD5 (boost_1_60_0_b1_rc1.7z) = ac6b2128d951ad688421fde2d878c2a7 MD5 (boost_1_60_0_b1_rc1.tar.bz2) = 2fc232f255f1ce8868315da207c05b6b MD5 (boost_1_60_0_b1_rc1.tar.gz) = d594e10f2761abaf957a67c6a223d2a4 MD5 (boost_1_60_0_b1_rc1.zip) = 16a2d512fca7995d5fa421d13f841b0f
When using clang, Boost.Spirit is failed to build on Linux and Android. This is reflected in testing matrix for master ([1], [2]), and this is still in beta. This is regression since there was no such error in 1.59.0. [1] http://www.boost.org/development/tests/master/developer/output/teeks99-05b-U... [2] http://www.boost.org/development/tests/master/developer/CrystaX-NET-apilevel... -- Dmitry Moskalchuk
On 09 Nov 2015, at 16:52, Marshall Clow <mclow.lists@gmail.com> wrote:
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
ProductName: Mac OS X ProductVersion: 10.11.1 BuildVersion: 15B42 Apple LLVM version 7.0.0 (clang-700.1.76) Target: x86_64-apple-darwin15.0.0 Thread model: posix - - - darwin.compile.c++ bin.v2/libs/atomic/build/darwin-4.2.1/release/threading-multi/lockpool.o clang: warning: optimization flag '-finline-functions' is not supported clang: warning: argument unused during compilation: '-finline-functions’ (+ 475 other) - - - darwin.compile.c bin.v2/libs/container/build/darwin-4.2.1/release/threading-multi/alloc_lib.o In file included from libs/container/src/alloc_lib.c:19: In file included from libs/container/src/dlmalloc_ext_2_8_6.c:36: libs/container/src/dlmalloc_2_8_6.c:4085:27: warning: 'sbrk' is deprecated [-Wdeprecated-declarations] char* base = (char*)CALL_MORECORE(0); ^ libs/container/src/dlmalloc_2_8_6.c:1714:37: note: expanded from macro 'CALL_MORECORE' #define CALL_MORECORE(S) MORECORE_DEFAULT(S) ^ libs/container/src/dlmalloc_2_8_6.c:666:26: note: expanded from macro 'MORECORE_DEFAULT' #define MORECORE_DEFAULT sbrk ^ /usr/include/unistd.h:587:7: note: 'sbrk' has been explicitly marked deprecated here void *sbrk(int); ^ (+ 19 other) - - - In file included from libs/graph/src/read_graphviz_new.cpp:50: In file included from ./boost/graph/graphviz.hpp:28: In file included from ./boost/graph/compressed_sparse_row_graph.hpp:48: ./boost/mpl/print.hpp:50:19: warning: in-class initialization of non-static data member is a C++11 extension [-Wc++11-extensions] const int m_x = 1 / (sizeof(T) - sizeof(T)); (+ 29 other) - - - In file included from libs/test/src/execution_monitor.cpp:16: In file included from ./boost/test/impl/execution_monitor.ipp:31: In file included from ./boost/test/execution_monitor.hpp:21: In file included from ./boost/test/utils/class_properties.hpp:24: In file included from ./boost/preprocessor/seq/for_each.hpp:19: In file included from ./boost/preprocessor/repetition/for.hpp:44: In file included from ./boost/preprocessor/repetition/detail/for.hpp:20: ./boost/preprocessor/tuple/eat.hpp:23:26: warning: variadic macros are a C99 feature [-Wvariadic-macros] # define BOOST_PP_EAT(…) (+ 2600 other) - - - In file included from libs/log/src/text_file_backend.cpp:50: In file included from ./boost/spirit/home/qi/numeric/numeric_utils.hpp:16: In file included from ./boost/spirit/home/qi/detail/assign_to.hpp:18: In file included from ./boost/spirit/home/qi/detail/attributes.hpp:12: ./boost/spirit/home/support/attributes.hpp:1156:23: error: no matching constructor for initialization of 'boost::none_t' val = none_t(); // leave optional uninitialized ^ ./boost/none_t.hpp:32:12: note: candidate constructor not viable: requires 1 argument, but 0 were provided explicit none_t(init_tag){} // to prevent default constructor ^ ./boost/none_t.hpp:29:8: note: candidate constructor (the implicit copy constructor) not viable: requires 1 argument, but 0 were provided struct none_t (+ 19 other) - - - In file included from libs/math/build/../src/tr1/pch.hpp:9: In file included from ./boost/math/special_functions.hpp:71: ./boost/math/special_functions/relative_difference.hpp:87:34: error: use of undeclared identifier 'a' if((boost::math::isnan)(a) || (boost::math::isnan)(b)) ^ ./boost/math/special_functions/relative_difference.hpp:87:61: error: use of undeclared identifier 'b' if((boost::math::isnan)(a) || (boost::math::isnan)(b)) ^ ./boost/math/special_functions/relative_difference.hpp:90:18: error: use of undeclared identifier 'b' if(fabs(b) > max_val) ^ ./boost/math/special_functions/relative_difference.hpp:92:21: error: use of undeclared identifier 'a' if(fabs(a) > max_val) ^ ./boost/math/special_functions/relative_difference.hpp:97:23: error: use of undeclared identifier 'a' else if(fabs(a) > max_val) ^ ./boost/math/special_functions/relative_difference.hpp:103:14: error: use of undeclared identifier 'a' if((a < 0) != (b < 0)) ^ ./boost/math/special_functions/relative_difference.hpp:103:25: error: use of undeclared identifier 'b' if((a < 0) != (b < 0)) ^ ./boost/math/special_functions/relative_difference.hpp:105:10: error: use of undeclared identifier 'a' a = fabs(a); ^ ./boost/math/special_functions/relative_difference.hpp:105:19: error: use of undeclared identifier 'a' a = fabs(a); ^ ./boost/math/special_functions/relative_difference.hpp:106:10: error: use of undeclared identifier 'b' b = fabs(b); ^ ./boost/math/special_functions/relative_difference.hpp:106:19: error: use of undeclared identifier 'b' b = fabs(b); ^ ./boost/math/special_functions/relative_difference.hpp:111:13: error: use of undeclared identifier 'a' if(a < min_val) ^ ./boost/math/special_functions/relative_difference.hpp:112:13: error: use of undeclared identifier 'a' a = min_val; ^ ./boost/math/special_functions/relative_difference.hpp:113:13: error: use of undeclared identifier 'b' if(b < min_val) ^ ./boost/math/special_functions/relative_difference.hpp:114:13: error: use of undeclared identifier 'b' b = min_val; ^ ./boost/math/special_functions/relative_difference.hpp:116:34: error: use of undeclared identifier 'a' return (std::max)(fabs((a - b) / a), fabs((a - b) / b)); ^ ./boost/math/special_functions/relative_difference.hpp:116:38: error: use of undeclared identifier 'b' return (std::max)(fabs((a - b) / a), fabs((a - b) / b)); ^ ./boost/math/special_functions/relative_difference.hpp:116:43: error: use of undeclared identifier 'a' return (std::max)(fabs((a - b) / a), fabs((a - b) / b)); ^ ./boost/math/special_functions/relative_difference.hpp:116:53: error: use of undeclared identifier 'a' return (std::max)(fabs((a - b) / a), fabs((a - b) / b)); ^ fatal error: too many errors emitted, stopping now [-ferror-limit=] 20 errors generated. "g++" -x c++-header -O3 -finline-functions -Wno-inline -Wall -gdwarf-2 -fexceptions -arch x86_64 -DBOOST_ALL_NO_LIB=1 -DBOOST_BUILD_PCH_ENABLED -DNDEBUG -I"." -I"libs/math/src/tr1" -c -o "bin.v2/libs/math/build/darwin-4.2.1/release/link-static/threading-multi/../src/tr1/pch.hpp.gch" "libs/math/build/../src/tr1/pch.hpp” - - - ...failed updating 14 targets... ...skipped 292 targets... ...updated 800 targets… - - - Performing configuration checks - 32-bit : no - 64-bit : yes - arm : no - mips1 : no - power : no - sparc : no - x86 : yes Building the Boost C++ Libraries. - symlinks supported : yes - lockfree boost::atomic_flag : yes - has_icu builds : no warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user-config.jam - zlib : yes - iconv (libc) : no - iconv (separate) : yes - icu : no - icu (lib64) : no - compiler-supports-visibility : yes - compiler-supports-ssse3 : yes - compiler-supports-avx2 : no - gcc visibility : yes - long double support : yes warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. - zlib : yes Component configuration: - atomic : building - chrono : building - container : building - context : building - coroutine : building - coroutine2 : building - date_time : building - exception : building - filesystem : building - graph : building - graph_parallel : building - iostreams : building - locale : building - log : building - math : building - mpi : building - program_options : building - python : building - random : building - regex : building - serialization : building - signals : building - system : building - test : building - thread : building - timer : building - type_erasure : building - wave : building ...patience... ...patience... ...patience... ...patience... ...patience... ...found 11809 targets... ...updating 1106 targets...
In file included from libs/math/build/../src/tr1/pch.hpp:9: In file included from ./boost/math/special_functions.hpp:71: ./boost/math/special_functions/relative_difference.hpp:87:34: error: use of undeclared identifier 'a' if((boost::math::isnan)(a) || (boost::math::isnan)(b))
I believe that's addressed in develop, will merge to master once it re-opens. Thanks for the heads-up, John.
On Mon, Nov 9, 2015 at 11:46 AM, John Maddock <jz.maddock@googlemail.com> wrote:
In file included from libs/math/build/../src/tr1/pch.hpp:9:
In file included from ./boost/math/special_functions.hpp:71: ./boost/math/special_functions/relative_difference.hpp:87:34: error: use of undeclared identifier 'a' if((boost::math::isnan)(a) || (boost::math::isnan)(b))
I believe that's addressed in develop, will merge to master once it re-opens.
John - If you have a fix for this that is already in develop (and has been tested there), please merge it to master. Thanks -- Marshall
On 09 Nov 2015, at 16:52, Marshall Clow <mclow.lists@gmail.com> wrote:
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
(I’ve omitted everything that was already in the clang build) ProductName: Mac OS X ProductVersion: 10.11.1 BuildVersion: 15B42 g++-5 (Homebrew gcc 5.2.0) 5.2.0 - - - darwin.compile.c++ bin.v2/libs/date_time/build/darwin-5.2.0/release/threading-multi/gregorian/greg_month.o In file included from libs/date_time/src/gregorian/greg_month.cpp:15:0: ./boost/date_time/gregorian/greg_facet.hpp: In function 'std::basic_istream<charT>& boost::gregorian::operator>>(std::basic_istream<charT>&, boost::gregorian::greg_month&)': ./boost/date_time/gregorian/greg_facet.hpp:293:12: warning: 'template<class> class std::auto_ptr' is deprecated [-Wdeprecated-declarations] std::auto_ptr< const facet_def > f(create_facet_def(a)); ^ In file included from /usr/local/Cellar/gcc/5.2.0/include/c++/5.2.0/memory:81:0, from ./boost/config/no_tr1/memory.hpp:21, from ./boost/smart_ptr/shared_ptr.hpp:23, from ./boost/shared_ptr.hpp:17, from ./boost/date_time/gregorian/greg_month.hpp:14, from libs/date_time/src/gregorian/greg_month.cpp:14: /usr/local/Cellar/gcc/5.2.0/include/c++/5.2.0/bits/unique_ptr.h:49:28: note: declared here template<typename> class auto_ptr; (+ 303 other) - - - darwin.compile.c++ bin.v2/libs/log/build/darwin-5.2.0/release/build-no/log-api-unix/threading-multi/thread_specific.o libs/log/src/thread_specific.cpp: In instantiation of 'static void boost::log::v2_mt_posix::aux::{anonymous}::pthread_key_traits<StorageT, true, false>::deallocate(StorageT&) [with StorageT = boost::log::v2_mt_posix::aux::thread_specific_base::key_storage]': libs/log/src/thread_specific.cpp:206:15: required from here libs/log/src/thread_specific.cpp:180:31: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] pthread_key_delete(*reinterpret_cast< pthread_key_type* >(&stg.as_dword)); (+ 21 other) - - - darwin.compile.c++ bin.v2/libs/log/build/darwin-5.2.0/release/build-no/log-api-unix/threading-multi/format_parser.o In file included from ./boost/spirit/home/qi/detail/attributes.hpp:12:0, from ./boost/spirit/home/qi/auxiliary/lazy.hpp:17, from ./boost/spirit/home/qi/detail/enable_lit.hpp:16, from ./boost/spirit/home/qi/numeric/uint.hpp:17, from ./boost/spirit/include/qi_uint.hpp:16, from libs/log/src/format_parser.cpp:22: ./boost/spirit/home/support/attributes.hpp:1070:12: error: redefinition of 'struct boost::spirit::traits::strip_single_element_vector<boost::fusion::vector<T> >' struct strip_single_element_vector<fusion::vector<T> > ^ ./boost/spirit/home/support/attributes.hpp:1064:12: error: previous definition of 'struct boost::spirit::traits::strip_single_element_vector<boost::fusion::vector<T> >' struct strip_single_element_vector<fusion::vector1<T> > ^ "/usr/local/bin/g++-5" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -dynamic -gdwarf-2 -fexceptions -std=c++11 -fPIC -arch x86_64 -ftemplate-depth-1024 -fvisibility=hidden -DBOOST_ALL_NO_LIB=1 -DBOOST_ATOMIC_DYN_LINK=1 -DBOOST_CHRONO_DYN_LINK=1 -DBOOST_DATE_TIME_DYN_LINK=1 -DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_LOG_BUILDING_THE_LIB=1 -DBOOST_LOG_DLL -DBOOST_LOG_USE_NATIVE_SYSLOG -DBOOST_LOG_WITHOUT_EVENT_LOG -DBOOST_SPIRIT_USE_PHOENIX_V3=1 -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_DONT_USE_CHRONO=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_USE_DLL=1 -DDATE_TIME_INLINE -DNDEBUG -I"." -c -o "bin.v2/libs/log/build/darwin-5.2.0/release/build-no/log-api-unix/threading-multi/format_parser.o" "libs/log/src/format_parser.cpp” (+ 11 other) - - - darwin.archive bin.v2/libs/locale/build/darwin-5.2.0/release/link-static/threading-multi/libboost_locale.a /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: warning same member name (codecvt.o) in output file used for input files: bin.v2/libs/locale/build/darwin-5.2.0/release/link-static/threading-multi/posix/codecvt.o and: bin.v2/libs/locale/build/darwin-5.2.0/release/link-static/threading-multi/std/codecvt.o (due to use of basename, truncation, blank padding or duplicate input files) /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: warning same member name (collate.o) in output file used for input files: bin.v2/libs/locale/build/darwin-5.2.0/release/link-static/threading-multi/posix/collate.o and: bin.v2/libs/locale/build/darwin-5.2.0/release/link-static/threading-multi/std/collate.o (due to use of basename, truncation, blank padding or duplicate input files) /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: warning same member name (converter.o) in output file used for input files: bin.v2/libs/locale/build/darwin-5.2.0/release/link-static/threading-multi/posix/converter.o and: bin.v2/libs/locale/build/darwin-5.2.0/release/link-static/threading-multi/std/converter.o (due to use of basename, truncation, blank padding or duplicate input files) /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: warning same member name (numeric.o) in output file used for input files: bin.v2/libs/locale/build/darwin-5.2.0/release/link-static/threading-multi/std/numeric.o and: bin.v2/libs/locale/build/darwin-5.2.0/release/link-static/threading-multi/posix/numeric.o (due to use of basename, truncation, blank padding or duplicate input files) - - - ...failed updating 14 targets... ...skipped 292 targets... ...updated 793 targets... - - - Performing configuration checks - 32-bit : no - 64-bit : yes - arm : no - mips1 : no - power : no - sparc : no - x86 : yes Building the Boost C++ Libraries. - symlinks supported : yes - lockfree boost::atomic_flag : yes - has_icu builds : no warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user-config.jam - zlib : yes - iconv (libc) : no - iconv (separate) : yes - icu : no - icu (lib64) : no - compiler-supports-visibility : yes - compiler-supports-ssse3 : no - compiler-supports-avx2 : no - gcc visibility : yes - long double support : yes warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. - zlib : yes Component configuration: - atomic : building - chrono : building - container : building - context : building - coroutine : building - coroutine2 : building - date_time : building - exception : building - filesystem : building - graph : building - graph_parallel : building - iostreams : building - locale : building - log : building - math : building - mpi : building - program_options : building - python : building - random : building - regex : building - serialization : building - signals : building - system : building - test : building - thread : building - timer : building - type_erasure : building - wave : building ...patience... ...patience... ...patience... ...patience... ...patience... ...found 11801 targets... ...updating 1099 targets...
On Mon, Nov 9, 2015 at 9:52 AM, Marshall Clow <mclow.lists@gmail.com> wrote:
Release candidate files for 1.60.0 beta 1 are available at http://boost.cowic.de/rc/
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
Errors when building libraries for visual studio: test and type_erasure. I've grabbed the repeated outputs and posted below. Full logs are at: 32-Bit: https://gist.github.com/teeks99/bed0ef4204d24677fa4e 64-Bit: https://gist.github.com/teeks99/6d0358817ddfe43724f7 Tom ------------ /libs/test msvc-8.0, msvc-9.0 ------------ compile-c-c++ bin.v2\libs\test\build\msvc-8.0\debug\link-static\runtime-link-static\threading-multi\unit_test_parameters.obj unit_test_parameters.cpp C:\Program Files (x86)\Microsoft Visual Studio 8\VC\INCLUDE\utility(35) : warning C4181: qualifier applied to reference type; ignored .\boost/test/utils/runtime/cla/parser.hpp(199) : see reference to class template instantiation 'std::pair<_Ty1,_Ty2>' being compiled with [ _Ty1=const boost::runtime::parameter_cla_id &, _Ty2=boost::runtime::basic_param_ptr ] C:\Program Files (x86)\Microsoft Visual Studio 8\VC\INCLUDE\utility(35) : warning C4181: qualifier applied to reference type; ignored C:\Program Files (x86)\Microsoft Visual Studio 8\VC\INCLUDE\utility(35) : error C2529: '_Val1' : reference to reference is illegal .\boost/test/utils/runtime/cla/parser.hpp(474) : error C2665: 'std::pair<_Ty1,_Ty2>::pair' : none of the 3 overloads could convert all the argument types with [ _Ty1=const boost::runtime::parameter_cla_id &, _Ty2=boost::runtime::basic_param_ptr ] C:\Program Files (x86)\Microsoft Visual Studio 8\VC\INCLUDE\utility(35): could be 'std::pair<_Ty1,_Ty2>::pair(_Ty1 (&),const _Ty2 &)' with [ _Ty1=const boost::runtime::parameter_cla_id &, _Ty2=boost::runtime::basic_param_ptr ] while trying to match the argument list '(const boost::runtime::parameter_cla_id, boost::runtime::basic_param_ptr)' call "C:\Users\tomkent\AppData\Local\Temp\b2_msvc_8.0_vcvarsall_x86.cmd" >nul cl /Zm800 -nologo @"bin.v2\libs\test\build\msvc-8.0\debug\link-static\runtime-link-static\threading-multi\unit_test_parameters.obj.rsp" ...failed compile-c-c++ bin.v2\libs\test\build\msvc-8.0\debug\link-static\runtime-link-static\threading-multi\unit_test_parameters.obj... ------------ /libs/type_erasure msvc-8.0, msvc-9.0, msvc-10.0 ------------ compile-c-c++ bin.v2\libs\type_erasure\build\msvc-8.0\debug\link-static\runtime-link-static\threading-multi\dynamic_binding.obj dynamic_binding.cpp C:\Program Files (x86)\Microsoft Visual Studio 8\VC\INCLUDE\utility(32) : error C2248: 'boost::shared_mutex::shared_mutex' : cannot access private member declared in class 'boost::shared_mutex' .\boost/thread/win32/shared_mutex.hpp(87) : see declaration of 'boost::shared_mutex::shared_mutex' .\boost/thread/win32/shared_mutex.hpp(28) : see declaration of 'boost::shared_mutex' C:\Program Files (x86)\Microsoft Visual Studio 8\VC\INCLUDE\utility(30) : while compiling class template member function 'std::pair<_Ty1,_Ty2>::pair(void)' with [ _Ty1=`anonymous-namespace'::map_type, _Ty2=`anonymous-namespace'::mutex_type ] libs\type_erasure\src\dynamic_binding.cpp(30) : see reference to class template instantiation 'std::pair<_Ty1,_Ty2>' being compiled with [ _Ty1=`anonymous-namespace'::map_type, _Ty2=`anonymous-namespace'::mutex_type ] call "C:\Users\tomkent\AppData\Local\Temp\b2_msvc_8.0_vcvarsall_x86.cmd" >nul cl /Zm800 -nologo @"bin.v2\libs\type_erasure\build\msvc-8.0\debug\link-static\runtime-link-static\threading-multi\dynamic_binding.obj.rsp" ...failed compile-c-c++ bin.v2\libs\type_erasure\build\msvc-8.0\debug\link-static\runtime-link-static\threading-multi\dynamic_binding.obj...
Marshall Clow-2 wrote
Release candidate files for 1.60.0 beta 1 are available at http://boost.cowic.de/rc/
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
Boost.Graph is now doubly broken on MSVC 14. Two important commits are missing in master: https://github.com/boostorg/graph/commit/1d5f43d9f6e8a5295bad7593db942cc755e... https://github.com/boostorg/graph/commit/0fc1749bd7b300b0ad7a6ec45eefff5ea90... BTW, there are commits in master now that are not in develop as a pull request has been merged to master instead of develop. And there is now some annoying output that spams one of my builds using Boost.Iostreams: NOTE: Use of this header (bool_trait_def.hpp) is deprecated NOTE: Use of this header (template_arity_spec.hpp) is deprecated There is a pull request that fixes this issue: https://github.com/boostorg/iostreams/pull/15 Everything else is working fine for me on MSVC 12 Update 5 32-bit and MSVC 14 Update 1 RC 64-bit. I compiled all Boost libraries and a few projects using Boost. -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-1-60-0-beta-1-Release-Candidates-av... Sent from the Boost - Dev mailing list archive at Nabble.com.
On Mon, Nov 9, 2015 at 7:52 AM, Marshall Clow <mclow.lists@gmail.com> wrote:
Release candidate files for 1.60.0 beta 1 are available at http://boost.cowic.de/rc/
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
To summarize where I think we are: 0) There were some problems with Spirit, which caused Log not to build. Those have been fixed. 1) There's some problem with "math/special_functions/relative_difference.hpp", etc. John thought he had a fix, but then he recanted. :-) John, what's the status of this? 2) Marcel says that there are two unmerged changes in Boost.Graph
Boost.Graph is now doubly broken on MSVC 14. Two important commits are missing in master:
https://github.com/boostorg/graph/commit/1d5f43d9f6e8a5295bad7593db942cc755e...
https://github.com/boostorg/graph/commit/0fc1749bd7b300b0ad7a6ec45eefff5ea90...
Marcel - what are the status of these patches on develop? Are they independent of other changes on develop? (i.e, can they be cherry-picked)? (They look pretty benign to me) 3) Tom reported errors when building libraries for visual studio: test and type_erasure. Raffi says that he has fixes for these. Raffi - Have these fixes been committed to develop? and what do the tests look like? Have I missed anything? Thanks, everyone -- Marshall
On 11 Nov 2015, at 05:41, Marshall Clow <mclow.lists@gmail.com> wrote:
Have I missed anything?
I’ve looked into the build related warnings for OS X: The main problem seems be that ‘darwin.jam' defaults to gcc which is just a front-end for clang for quite some time now. Fortunately there is already ‘clang-darwin.jam’ for current versions of OS X. The second problem is the use of C++11 code without providing the corresponding compiler option. So the correct command line for building Boost with a recent OS X version is as follows (and which should probably become the default at some point in the future): ./b2 toolset=clang-darwin cxxflags=-std=c++11 Thomas
On Wed, Nov 11, 2015 at 11:47 AM, Thomas Trummer <th.trummer@gmail.com> wrote:
On 11 Nov 2015, at 05:41, Marshall Clow <mclow.lists@gmail.com> wrote:
Have I missed anything?
I’ve looked into the build related warnings for OS X: The main problem seems be that ‘darwin.jam' defaults to gcc which is just a front-end for clang for quite some time now. Fortunately there is already ‘clang-darwin.jam’ for current versions of OS X. The second problem is the use of C++11 code without providing the corresponding compiler option. So the correct command line for building Boost with a recent OS X version is as follows (and which should probably become the default at some point in the future):
./b2 toolset=clang-darwin cxxflags=-std=c++11
I have a custom toolset which is exactly that "clang-darwin-11" (also clang-darwin-14 and clang-darwin-1z, for that matter :-)) -- Marshall
participants (23)
-
Andrey Semashev -
Artyom Beilis -
Bjorn Reese -
Dmitry Moskalchuk -
Edward Diener -
Gavin Lambert -
Howard Hinnant -
Ion Gaztañaga -
John Maddock -
Jonathan Wakely -
Karen Shaeffer -
Marcel Raad -
Marshall Clow -
Mateusz Loskot -
Nevin Liber -
Nevin Liber -
Peter Dimov -
Stephan T. Lavavej -
Thomas Trummer -
Tom Kent -
Vladimir Batov -
Vladimir Prus -
Zach Laine