Where we are 1.65.0

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Where we are 1.65.0

Boost - Dev mailing list
RC1 came out on Monday, and it had some problems.

Specifically:
* Some libraries didn't build with ToT clang/libc++  (Locale, Wave and Test)
This is because in C++17, some deprecated library features have been
removed.  [bind1st, mem_fun, auto_ptr, random_shuffle, etc ]

Boost.Config has support for these removals, but this was ... incomplete.
[ This is on me; I did the partial job of adding these to Config's libc++
support a while back ]

Normally, I would be tempted to say "Well, clang 5 is not shipping yet, and
so we can put this off until 1.66.0". But both clang 5 and C++17 are
imminent (they will both happen well before the 1.66 release, and so I
think we should fix this now. Also, a future version of MSVC will have the
same library issues.

So I have committed a fix for Boost.Config that fixes the Boost.Test issues.
Hartmut has fixed most of the Boost.Wave issues.
Artymom has a fix for Boost.Locale.

Windows/MSVC builds look good across the board.


* Boost.Fiber fails to build on Mac OS with anything other than -std=c++03.
There is a fix in develop for this; but there's still a bunch of tests
failing.

* There's a problem from the beta in Boost.Math.

The regression regarding boost/math/common_factor_ct.hpp (vs
> math_fwd.hpp) seems to be still there. (For details please see the
> original mail and replies:
> https://lists.boost.org/Archives/boost/2017/07/237452.php)




> What I presume is the fix (https://github.com/boostorg/math/pull/75) was
> merged into develop about 12 hours ago, some automatic CI tests still
> running.


* There's a problem with ScopeExit and Visual C++ 2017

With Visual C++ 2017 and /permissive-, ScopeExit is still broken, for which
> there's an open PR:
> https://github.com/boostorg/scope_exit/pull/3




> Looks good otherwise on MSVC 14.11, tested with /std=cpplatest and
> _HAS_AUTO_PTR_ETC=1, targeting Windows 10 and XP, 32 bit and 64 bit, built
> as static libraries.
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Where we are 1.65.0

Boost - Dev mailing list
[Marshall Clow]
> * Some libraries didn't build with ToT clang/libc++  (Locale, Wave and Test)
> This is because in C++17, some deprecated library features have been removed.
> [bind1st, mem_fun, auto_ptr, random_shuffle, etc ]
> Boost.Config has support for these removals, but this was ... incomplete.
> [ This is on me; I did the partial job of adding these to Config's libc++ support a while back ]
> Normally, I would be tempted to say "Well, clang 5 is not shipping yet, and so we can put
> this off until 1.66.0". But both clang 5 and C++17 are imminent (they will both happen well
> before the 1.66 release, and so I think we should fix this now.

> Also, a future version of MSVC will have the same library issues.

This was actually implemented in MSVC 2015 RTM, as opt-in behavior. In MSVC 2015.3 when /std:c++latest was added, we made C++17 mode remove auto_ptr/etc. by default (with the same macro being used for opt-out).

I would like to gently point out that I gave Boost a heads-up when all of this happened, in classic emails like "Removing auto_ptr/etc. from Boost" on March 18, 2015 and "Boost and auto_ptr (was Boost 1.60.0 beta 1...)" on November 11, 2015.

We're treating the other C++17 removals identically. The old iostreams members are hopefully totally irrelevant, the std::function allocator support probably is too (I would expect boost::function to be used), but std::unexpected() removal may be relevant. That one's going to be enabled by /std:c++17 and /std:c++latest in 2017's second toolset update.

As a reminder, "std::auto_ptr in public interfaces" on May 20, 2017 is repeating this cycle, with early notification of deprecation warnings:

[STL]
> Additionally, in VC 2017's second toolset update (not the first one that's being released soon),
> I am planning to aggressively warn about C++17's deprecated features in C++17 mode (/std:c++17
> or /std:c++latest). All of the library stuff in Annex D will emit warnings, except for the <meow.h>
> C headers (it's silly that they're deprecated). [snipped outdated sentence] This is going to be
> pretty noisy, but it'll ultimately make migrating code to C++20 and beyond easier.

> I plan to have a system of fine-grained escape hatch macros, and a big "silence all C++17 deprecation
> warnings" macro, but libraries like Boost will need to avoid the deprecated components (or locally
> suppress C4996) since they don't really control the user's preferences.

> Auditing Boost right now for unnecessary use of the Annex D stuff would be a good idea.
> Stuff like std::iterator, the old allocator members, and std::result_of are probably commonly used.

Thanks,
STL

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Where we are 1.65.0

Boost - Dev mailing list


On 09/08/2017 19:20, Stephan T. Lavavej via Boost wrote:

> [Marshall Clow]
>> * Some libraries didn't build with ToT clang/libc++  (Locale, Wave and Test)
>> This is because in C++17, some deprecated library features have been removed.
>> [bind1st, mem_fun, auto_ptr, random_shuffle, etc ]
>> Boost.Config has support for these removals, but this was ... incomplete.
>> [ This is on me; I did the partial job of adding these to Config's libc++ support a while back ]
>> Normally, I would be tempted to say "Well, clang 5 is not shipping yet, and so we can put
>> this off until 1.66.0". But both clang 5 and C++17 are imminent (they will both happen well
>> before the 1.66 release, and so I think we should fix this now.
>> Also, a future version of MSVC will have the same library issues.
> This was actually implemented in MSVC 2015 RTM, as opt-in behavior. In MSVC 2015.3 when /std:c++latest was added, we made C++17 mode remove auto_ptr/etc. by default (with the same macro being used for opt-out).
>
> I would like to gently point out that I gave Boost a heads-up when all of this happened, in classic emails like "Removing auto_ptr/etc. from Boost" on March 18, 2015 and "Boost and auto_ptr (was Boost 1.60.0 beta 1...)" on November 11, 2015.
>
> We're treating the other C++17 removals identically. The old iostreams members are hopefully totally irrelevant, the std::function allocator support probably is too (I would expect boost::function to be used), but std::unexpected() removal may be relevant. That one's going to be enabled by /std:c++17 and /std:c++latest in 2017's second toolset update.
>
> As a reminder, "std::auto_ptr in public interfaces" on May 20, 2017 is repeating this cycle, with early notification of deprecation warnings:

I don't believe anyone is blaming you for this, I think it's just that
this is the first time we've had to deal with removals from the std lib
and have been slow off the mark.

I wonder if we should have a blanket check for C++17 in suffix.hpp which
would then set these macros regardless of compiler if it claims to be in
C++17 mode?  That won't help with VC++ which hasn't updated __cplusplus
in a while, but would have avoided the clang issue...

Best, John.

---
This email has been checked for viruses by AVG.
http://www.avg.com


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Where we are 1.65.0

Boost - Dev mailing list
[John Maddock]
> I wonder if we should have a blanket check for C++17 in suffix.hpp which would
> then set these macros regardless of compiler if it claims to be in
> C++17 mode?  That won't help with VC++ which hasn't updated __cplusplus
> in a while, but would have avoided the clang issue...

_MSVC_LANG indicates whether /std:c++14, /std:c++17, or /std:c++latest is being used. You can test it like this:

#ifndef YOUR_CXX17_MACRO
 #ifdef _MSVC_LANG
  #if _MSVC_LANG > 201402
   #define YOUR_CXX17_MACRO 1
  #else
   #define YOUR_CXX17_MACRO 0
  #endif
 #else
  #if __cplusplus > 201402
   #define YOUR_CXX17_MACRO 1
  #else
   #define YOUR_CXX17_MACRO 0
  #endif
 #endif
#endif

Alternatively, instead of asking the compiler, you can ask our STL whether it's in C++17 mode. Simply include any header (good old <ciso646> will do) and _HAS_CXX17 will be defined to either 0 or 1.

Thanks,
STL

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Where we are 1.65.0

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Le 09.08.17 à 20:20, Stephan T. Lavavej via Boost a écrit :
> [Marshall Clow]
>> * Some libraries didn't build with ToT clang/libc++  (Locale, Wave and Test)
>> This is because in C++17, some deprecated library features have been removed.
>> [bind1st, mem_fun, auto_ptr, random_shuffle, etc ]
>> Boost.Config has support for these removals, but this was ... incomplete.
>> [ This is on me; I did the partial job of adding these to Config's libc++ support a while back ]
>> Normally, I would be tempted to say "Well, clang 5 is not shipping yet, and so we can put
>> this off until 1.66.0". But both clang 5 and C++17 are imminent (they will both happen well
>> before the 1.66 release, and so I think we should fix this now.

Thanks for the feedback! and thanks again for the boost.test fixes!

>> Also, a future version of MSVC will have the same library issues.
>
> This was actually implemented in MSVC 2015 RTM, as opt-in behavior. In MSVC 2015.3 when /std:c++latest was added, we made C++17 mode remove auto_ptr/etc. by default (with the same macro being used for opt-out).
>
> I would like to gently point out that I gave Boost a heads-up when all of this happened, in classic emails like "Removing auto_ptr/etc. from Boost" on March 18, 2015 and "Boost and auto_ptr (was Boost 1.60.0 beta 1...)" on November 11, 2015.
>
> We're treating the other C++17 removals identically. The old iostreams members are hopefully totally irrelevant, the std::function allocator support probably is too (I would expect boost::function to be used), but std::unexpected() removal may be relevant. That one's going to be enabled by /std:c++17 and /std:c++latest in 2017's second toolset update.
>
> As a reminder, "std::auto_ptr in public interfaces" on May 20, 2017 is repeating this cycle, with early notification of deprecation warnings:
>
> [STL]
>> Additionally, in VC 2017's second toolset update (not the first one that's being released soon),
>> I am planning to aggressively warn about C++17's deprecated features in C++17 mode (/std:c++17
>> or /std:c++latest). All of the library stuff in Annex D will emit warnings, except for the <meow.h>
>> C headers (it's silly that they're deprecated). [snipped outdated sentence] This is going to be
>> pretty noisy, but it'll ultimately make migrating code to C++20 and beyond easier.
>
>> I plan to have a system of fine-grained escape hatch macros, and a big "silence all C++17 deprecation
>> warnings" macro, but libraries like Boost will need to avoid the deprecated components (or locally
>> suppress C4996) since they don't really control the user's preferences.
>
>> Auditing Boost right now for unnecessary use of the Annex D stuff would be a good idea.
>> Stuff like std::iterator, the old allocator members, and std::result_of are probably commonly used.
>
> Thanks,
> STL

You're right!

We definitely need runners for this, and the plethora of
architectures/compilers is well covered for established compilers, not
so well maybe for new compilers.

I do not know about the state of VS2017 /std:c++17, I believe teeks99-09
is doing it:
http://www.boost.org/development/tests/develop/teeks99-09-p-win2012R2-64on64.html 


Also, if I recall, the build was also having trouble for support of
VS2017, which ate up some resources.

OTOH,

* as a developer, I would say: bad luck, give me runners, and I will fix
the problems as I see them coming
* as a user, I would say: boost is so-so ahead of its time for C++ (and
many more bad things of course)

that makes me feel like:
* having support for "cutting edge" sounds to me better than "release
often", especially when the price is so low (most of the problems seems
to be fixed, we need to cycle the runners)
* fixing things in RCs, like now, is exactly the right time
* and fixing means also having runners for those compilers, so that the
development can go smoothly for next release. Having to wait half a
release cycle is too short for developments to my opinion.

I am all in favor of postponing the release and getting those fixed.

I am also wondering about several topics that are orthogonal to
developments:
* would a different branching policy help here? it has been mentioned
that some PRs are on the pipe, but those need to stage to develop and
then merged to master, which ultimately will pull some unwanted changes
that are not addressing the issues specific to the release
* would it make sense to share the know-how on how to set up a new
compiler? I am not referring to how to run the regression script, but
rather on how to install a test machine with a cutting edge compiler.
This is more an IT perspective, but maybe gathering that knowledge would
help us having more test machines?

Thanks,
Raffi



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Where we are 1.65.0

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Wed, Aug 9, 2017 at 7:26 PM, Marshall Clow via Boost
<[hidden email]> wrote:

> RC1 came out on Monday, and it had some problems.
>
> Specifically:
> * Some libraries didn't build with ToT clang/libc++  (Locale, Wave and Test)
> This is because in C++17, some deprecated library features have been
> removed.  [bind1st, mem_fun, auto_ptr, random_shuffle, etc ]
>
> Boost.Config has support for these removals, but this was ... incomplete.
> [ This is on me; I did the partial job of adding these to Config's libc++
> support a while back ]
>
> Normally, I would be tempted to say "Well, clang 5 is not shipping yet, and
> so we can put this off until 1.66.0". But both clang 5 and C++17 are
> imminent (they will both happen well before the 1.66 release, and so I
> think we should fix this now. Also, a future version of MSVC will have the
> same library issues.

Having C++17-capable clang and MSVC around the corner doesn't
necessarily mean that people will go right ahead and use it. There'll
be a transition period, which will surely exceed Boost release period.

Now, don't get me wrong, I'm all for fixing as many bugs as possible
before the release. But at least Boost.ScopeExit from the list you
presented doesn't have an active maintainer. Unless someone with push
permissions handles the fix, we don't have a certain date of it being
fixed. In this condition I'd rather have 1.65 released with the bug
now (with a note in the release notes) instead of waiting for unknown
period of time. In other words, I think we can postpone the release
but only if we have a plan on what, how and when we want to fix, with
a new realistic deadline. If we don't then just release what we have
now and postpone the rest for 1.66.

Is there an updated release schedule?

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Where we are 1.65.0

Boost - Dev mailing list
On Thu, Aug 10, 2017 at 12:41 AM, Andrey Semashev via Boost
<[hidden email]> wrote:
> Having C++17-capable clang and MSVC around the corner doesn't
> necessarily mean that people will go right ahead and use it. There'll

That's false. People (some) *will* use them. Not supporting them
basically means you're blocking those people from upgrading.
Note that existing compilers already have C++17 stuff and people *are* using it.



--
Olaf

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Where we are 1.65.0

Boost - Dev mailing list
On 08/10/17 09:53, Olaf van der Spek wrote:
> On Thu, Aug 10, 2017 at 12:41 AM, Andrey Semashev via Boost
> <[hidden email]> wrote:
>> Having C++17-capable clang and MSVC around the corner doesn't
>> necessarily mean that people will go right ahead and use it. There'll
>
> That's false. People (some) *will* use them. Not supporting them
> basically means you're blocking those people from upgrading.
> Note that existing compilers already have C++17 stuff and people *are* using it.

Of course, there are enthusiasts but most people will start using C++17
much later, e.g. when they upgrade the production system and it ships
the new compiler.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Where we are 1.65.0

Boost - Dev mailing list
On Thu, Aug 10, 2017 at 9:36 AM, Andrey Semashev via Boost
<[hidden email]> wrote:
>> That's false. People (some) *will* use them. Not supporting them
>> basically means you're blocking those people from upgrading.
>> Note that existing compilers already have C++17 stuff and people *are*
>> using it.
>
>
> Of course, there are enthusiasts but most people will start using C++17 much
> later, e.g. when they upgrade the production system and it ships the new
> compiler.

And?
Are you proposing to delay fixes until those people start complaining?

Note that both VS 2015 and 2017 have shipped and both are hitting
those issues already.

--
Olaf

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Where we are 1.65.0

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 2017-08-10 08:36, Andrey Semashev via Boost wrote:

> On 08/10/17 09:53, Olaf van der Spek wrote:
>> On Thu, Aug 10, 2017 at 12:41 AM, Andrey Semashev via Boost
>> <[hidden email]> wrote:
>>> Having C++17-capable clang and MSVC around the corner doesn't
>>> necessarily mean that people will go right ahead and use it. There'll
>>
>> That's false. People (some) *will* use them. Not supporting them
>> basically means you're blocking those people from upgrading.
>> Note that existing compilers already have C++17 stuff and people *are*
>> using it.
>
> Of course, there are enthusiasts but most people will start using
> C++17 much later, e.g. when they upgrade the production system and it
> ships the new compiler.

This is of course what most people will do.  But as a library author I
need to support new standards in advance of my users starting to use
them, so they aren't blocked by my tardiness.  Since I depend
significantly upon Boost, if Boost doesn't support new standards in a
timely manner, this blocks me, which then blocks my users.  I'm working
on enabling building everything with C++17 *today*, with the expectation
of having it fully working and a supported option within the next month
or so.

I certainly don't expect Boost to make much use of C++17 features, but I
consider being able to *compile and link* with "-std=c++17" and its cl
equivalent a fairly essential bar to meet for future Boost releases, and
IMO would be worth holding up the release for.  Otherwise we'll be
blocked on this for many months.


Regards,
Roger


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Where we are 1.65.0

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 10 August 2017 at 10:36, Andrey Semashev via Boost <[hidden email]
> wrote:

> Of course, there are enthusiasts but most people will start using C++17
> much later, e.g. when they upgrade the production system and it ships the
> new compiler.
>

In this particular transition, I'm not so sure, C++17 is really the
completion of C++11 and C++14, so those who did go to C++11, might want to
upgrade sooner than you think. Also, MSVC (current and eminent release) is
now in much better shape than it ever was. So those people are certainly
motivated.  Additionally, contrary to the past, the upgrade (full monty) is
free (Community Edition) for many. Equally so, on Windows, Clang/LLVM is
now up to scratch, certainly with the release of 5.0, planned for 23rd of
August.

Anecdotically, at CERN-Institute (some of the most advanced scientists)
they won't upgrade from what I understood, as they choose to stay on C++03.

degski
--
"*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend,
Schmerzen aus Schwäche stillend.*" - Novalis 1798

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Where we are 1.65.0

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 08/10/17 10:47, Olaf van der Spek wrote:

> On Thu, Aug 10, 2017 at 9:36 AM, Andrey Semashev via Boost
> <[hidden email]> wrote:
>>> That's false. People (some) *will* use them. Not supporting them
>>> basically means you're blocking those people from upgrading.
>>> Note that existing compilers already have C++17 stuff and people *are*
>>> using it.
>>
>> Of course, there are enthusiasts but most people will start using C++17 much
>> later, e.g. when they upgrade the production system and it ships the new
>> compiler.
>
> And?
> Are you proposing to delay fixes until those people start complaining?

I'm proposing to have 1.65 more or less in time so that people get other
fixes and features as planned. I'm opposed to delay to an unknown point
because that way noone is getting any fixes or features at all.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Where we are 1.65.0

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Thu, Aug 10, 2017 at 10:58 AM, degski via Boost <[hidden email]>
wrote:

> On 10 August 2017 at 10:36, Andrey Semashev via Boost <
> [hidden email]
> > wrote:
>
> > Of course, there are enthusiasts but most people will start using C++17
> > much later, e.g. when they upgrade the production system and it ships the
> > new compiler.
> >
>
> In this particular transition, I'm not so sure, C++17 is really the
> completion of C++11 and C++14, so those who did go to C++11, might want to
> upgrade sooner than you think. Also, MSVC (current and eminent release) is
> now in much better shape than it ever was. So those people are certainly
> motivated.  Additionally, contrary to the past, the upgrade (full monty) is
> free (Community Edition) for many. Equally so, on Windows, Clang/LLVM is
> now up to scratch, certainly with the release of 5.0, planned for 23rd of
> August.
>
> Anecdotically, at CERN-Institute (some of the most advanced scientists)
> they won't upgrade from what I understood, as they choose to stay on C++03.
>

​It's true that at CERN they are doing some of the most advanced (and
important) science and data processing. But that doesn't mean that, outside
of that most important field, that's a good indication of C++ needs for
other people. From my past experience as a physicist, I can recall not so
many years ago that a lot of work in physics was done in Fortran 77, not
because other tools were not available or preferred but mostly because of
inertia (of course, that's IMHO). ​I have a fondly remembrance of that, but
that is because I was young. In objective terms, it was less than amazing
:-)

Just my 2 cents.

Best regards,
Francesco

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Where we are 1.65.0

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Thu, Aug 10, 2017 at 3:47 AM, Olaf van der Spek wrote:

> On Thu, Aug 10, 2017 at 9:36 AM, Andrey Semashev wrote:
>>> That's false. People (some) *will* use them. Not supporting them
>>> basically means you're blocking those people from upgrading.
>>> Note that existing compilers already have C++17 stuff and people *are*
>>> using it.
>>
>>
>> Of course, there are enthusiasts but most people will start using C++17 much
>> later, e.g. when they upgrade the production system and it ships the new
>> compiler.
>
> And?
> Are you proposing to delay fixes until those people start complaining?

That's not what he's proposing at all, is it?

Boost has a release schedule. People are waiting for Boost 1.65 -
either for fixes, or sometimes new features. Andrey is simply
suggesting that releasing 1.65 is more important right now, to keep to
that release schedule.There are people and groups who take
dependencies on Boost libraries not just because of the quality, but
because Boost releases frequently.

If we're balancing getting a Boost 1.65 release on time instead of
delaying it by a few weeks, versus releasing 1.65 with C++17 support
now instead of three months from now, Andrey's suggestion is not
unreasonable. C++17 will hopefully even be a published ISO standard by
the time 1.66 releases.

(December is when users would be able to hopefully expect 1.66,
ceteris paribus - assuming no more delays for 1.65, based on the
release schedule)


Glen

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Where we are 1.65.0

Boost - Dev mailing list
FYI The scope_exit issue was being caused by Typeof, I've filed a PR for
that: https://github.com/boostorg/typeof/pull/9

I guess the options we have are either:

* Have a big push over the next week to fix any remaining C++17 issues
and delay the release accordingly, or
* Make the release now, and issue a .1 release in say a month's time
with bug fixes only (not only C++17 ones).

I have no real though which is preferable to be honest.

Best, John.

---
This email has been checked for viruses by AVG.
http://www.avg.com


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [c++17] Where we are 1.65.0

Boost - Dev mailing list
A quick survey for C++17 issues in *develop* finds:

auto_ptr:

~~~~~~~~~

assign

asio (tests do all pass actually with msvc in C++17 mode, but I can't
see where/how auto_ptr usage is controlled).

ptr_container

python (it has a workaround in place, but replies on __cplusplus being
set to the correct value, which is not the case for msvc).

statechart.

typeof (PR submitted)


unary/binary_function:

~~~~~~~~~~~~~~~~~~~~

functional (has own workaround that's std lib specific, won't work for
everything else?)

bimap

hash (has own workaround that's std lib specific, won't work for
everything else?)

Gil

ICL

MPI


bind1st/2nd:

~~~~~~~~~~~~~

GIL

Random

Spirit


Random_shuffle:

~~~~~~~~~~~~~~~

Compute

Graph

lambda

MSM


So there's a bit of work to do to fully fix this.

John.

---
This email has been checked for viruses by AVG.
http://www.avg.com


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Where we are 1.65.0

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Thu, Aug 10, 2017 at 4:40 AM, John Maddock via Boost <
[hidden email]> wrote:

> FYI The scope_exit issue was being caused by Typeof, I've filed a PR for
> that: https://github.com/boostorg/typeof/pull/9
>
> I guess the options we have are either:
>
> * Have a big push over the next week to fix any remaining C++17 issues and
> delay the release accordingly, or
> * Make the release now, and issue a .1 release in say a month's time with
> bug fixes only (not only C++17 ones).
>
> I have no real though which is preferable to be honest.
>

My plan is quite limited

* Take a few patches that were already landed on develop and merge to
master (wave, fiber, config).  Artymom has indicated to me that he's not
comfortable with rushing the changes to locale, so we won't be doing that.

* Make an RC2 - preferably today

I'm not really interested in making large-scale changes post-beta (thanks
for the survey, John!).

-- Marshall

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Where we are 1.65.0

Boost - Dev mailing list
Am 10.08.2017 um 15:37 schrieb Marshall Clow via Boost:
> On Thu, Aug 10, 2017 at 4:40 AM, John Maddock via Boost <
> [hidden email]> wrote:
>
> I'm not really interested in making large-scale changes post-beta (thanks
> for the survey, John!).

I had filed PR for algorithm, assign, bimap, gil, icl, msm, polygon,
ptr_container, random, statechart, typeof (and many others) fixing these
C++17 problems a couple of months ago. According to my list of open PRs,
the mentioned ones are still waiting to be merged, all the others got
attention.

Ciao
  Dani

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [c++17] Where we are 1.65.0

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Thu, Aug 10, 2017 at 2:31 PM, John Maddock via Boost
<[hidden email]> wrote:
> A quick survey for C++17 issues in *develop* finds:

> unary/binary_function:
>
> ~~~~~~~~~~~~~~~~~~~~
>
> functional (has own workaround that's std lib specific, won't work for
> everything else?)
>
> bimap
>
> hash (has own workaround that's std lib specific, won't work for everything
> else?)
>
> Gil
>
> ICL
>
> MPI

rc2: c:\vc\boost\boost\numeric\conversion\detail\converter.hpp:
struct trivial_converter_impl : public std::unary_function<
BOOST_DEDUCED_TYPENAME Traits::argument_type

Does this mean it's fixed in develop but not in master / rc2?

Gr,

Olaf

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Where we are 1.65.0

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Thu, Aug 10, 2017 at 3:37 PM, Marshall Clow via Boost
<[hidden email]> wrote:

> My plan is quite limited
>
> * Take a few patches that were already landed on develop and merge to
> master (wave, fiber, config).  Artymom has indicated to me that he's not
> comfortable with rushing the changes to locale, so we won't be doing that.
>
> * Make an RC2 - preferably today
>
> I'm not really interested in making large-scale changes post-beta (thanks
> for the survey, John!).

Will there be a .1 with support for C++17 or will that have to wait for 1.66?


--
Olaf

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
12
Loading...