Patch bonanza for VS2013 Preview support

classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Patch bonanza for VS2013 Preview support

Lars Viklund
Hi list.

What's the best way to spend your vacation if not trying to get
Boost to build on bleeding-edge compilers. I set out to see how well
Boost 1.54.0 behaved on the newly released go-live-ready Visual Studio
2013 Preview. Below is the list of bugs filed against Boost and
Microsoft. Enjoy.

With these patches in place, I can get a complete build working with all
libraries normally available on a fresh machine (means that I didn't
test Python, MPI, ICU, compressed streams).

I haven't been able to find out how to run the tests in any
human-readable form, but this should not cause any regressions as it's
either increasing workaround bounds or adding headers that the standard
mandates already.

Boost.Config VS2013 Preview version bump
https://svn.boost.org/trac/boost/ticket/8753
The Visual Studio 2013 Preview toolchain has _MSC_VER 1800 and
_MSC_FULL_VER 180020617. See the attached patch for the minimum changes
that are needed to get anywhere at all.

Boost.Build needs support for the VS2013 Preview toolset (18.00.20617.1)
https://svn.boost.org/trac/boost/ticket/8754
Visual Studio 2013 Preview is out and claims to be 12.0. I copy-pasted
everything related to 11.0 to refer to 12.0 and it Works On My Machine,
see attached patch.

Boost.Signals VS2013 Preview version bump
https://svn.boost.org/trac/boost/ticket/8755
The BOOST_WORKAROUND macros at
boost/signals/detail/named_slot_map.hpp:130 and
libs/signals/src/named_slot_map.cpp:27 needs to be increased to <= 1800
in order to encompass the Visual Studio 2013 Preview compiler.

Boost.MPL VS2013 Preview version bump
https://svn.boost.org/trac/boost/ticket/8756
The BOOST_WORKAROUND macros at boost/mpl/assert.hpp lines 37 and 247
need to be changed to also consider BOOST_MSVC, == 1800, patch attached.

Boost.Serialization lacks algorithm header include for std::min
https://svn.boost.org/trac/boost/ticket/8757
The <algorithm> header providing std::min is not included in
boost/archive/iterators/transform_width.hpp, this breaks on Visual
Studio 2013 Preview due to library changes.

Boost.Asio lacks algorithm header include for std::min
https://svn.boost.org/trac/boost/ticket/8758
The <algorithm> header providing std::min is not included in
boost/asio/detail/impl/win_iocp_io_service.hpp, this breaks on Visual
Studio 2013 Preview due to library changes.

std::bind broken with boost/tuple/tuple.hpp or anything else providing a ADL tie
https://connect.microsoft.com/VisualStudio/feedback/details/792163/std-bind-lack-of-qualifier-on-tie-finds-non-std-tie-by-adl
Not our fault, I filed a bug on Connect and am hoping that they'll
notice it before RTM. 'std::bind' finds our 'tie' if a type from a boost
namespace is used in the 'std::function' argument type list.

--
Lars Viklund | [hidden email]

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

Re: Patch bonanza for VS2013 Preview support

Stephan T. Lavavej-2
[Lars Viklund]
> std::bind broken with boost/tuple/tuple.hpp or anything else providing a ADL tie
> https://connect.microsoft.com/VisualStudio/feedback/details/792163/std-bind-lack-of-qualifier-on-tie-finds-non-std-tie-by-adl
> Not our fault, I filed a bug on Connect and am hoping that they'll
> notice it before RTM. 'std::bind' finds our 'tie' if a type from a boost
> namespace is used in the 'std::function' argument type list.

I've assigned this bug to myself; fixing it should be trivial. We try to be really careful about slapping _STD (our macro for ::std::) on everything, but we missed this one.

Thanks,
STL


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

Re: Patch bonanza for VS2013 Preview support

Mathias Gaunard-2
In reply to this post by Lars Viklund
On 02/07/13 01:35, Lars Viklund wrote:

> Boost.Signals VS2013 Preview version bump
> https://svn.boost.org/trac/boost/ticket/8755
> The BOOST_WORKAROUND macros at
> boost/signals/detail/named_slot_map.hpp:130 and
> libs/signals/src/named_slot_map.cpp:27 needs to be increased to <= 1800
> in order to encompass the Visual Studio 2013 Preview compiler.
>
> Boost.MPL VS2013 Preview version bump
> https://svn.boost.org/trac/boost/ticket/8756
> The BOOST_WORKAROUND macros at boost/mpl/assert.hpp lines 37 and 247
> need to be changed to also consider BOOST_MSVC, == 1800, patch attached.

I'm not sure fixing these right now is a good idea, since it's just a
preview version. The final version will also be 1800, and it might
behave differently.

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

Re: Patch bonanza for VS2013 Preview support

Lars Viklund
On Tue, Jul 02, 2013 at 12:38:29PM +0200, Mathias Gaunard wrote:

> On 02/07/13 01:35, Lars Viklund wrote:
>
>> Boost.Signals VS2013 Preview version bump
>> https://svn.boost.org/trac/boost/ticket/8755
>> The BOOST_WORKAROUND macros at
>> boost/signals/detail/named_slot_map.hpp:130 and
>> libs/signals/src/named_slot_map.cpp:27 needs to be increased to <= 1800
>> in order to encompass the Visual Studio 2013 Preview compiler.
>>
>> Boost.MPL VS2013 Preview version bump
>> https://svn.boost.org/trac/boost/ticket/8756
>> The BOOST_WORKAROUND macros at boost/mpl/assert.hpp lines 37 and 247
>> need to be changed to also consider BOOST_MSVC, == 1800, patch attached.
>
> I'm not sure fixing these right now is a good idea, since it's just a  
> preview version. The final version will also be 1800, and it might  
> behave differently.

How about a workaround using the _MSC_FULL_VER of this release then
where suitable?

Note that this isn't like the previous CTPs, it has the go-live blessing
from the vendor that allows its use in production.

In my eyes there's two paths here:
a) do nothing, and both the Preview and the RTM will be broken until at
least the Boost version shipping after RTM is available;
b) implement sufficient fixes for Boost to work with the Preview,
allowing people to find and report issues, and when RTM ships, have a
chance of at least some support in a released Boost version.

Is it really worth some effort saving now to have a multi-month period
at RTM launch where the compiler is utterly unusable?

This is after all one of the top-tier toolchains that Boost aims to
support.

--
Lars Viklund | [hidden email]

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

Re: Patch bonanza for VS2013 Preview support

Daniel James-2
In reply to this post by Lars Viklund
On Tue, 2 Jul 2013, at 01:35 AM, Lars Viklund wrote:
>
> Boost.Signals VS2013 Preview version bump
> https://svn.boost.org/trac/boost/ticket/8755
> The BOOST_WORKAROUND macros at
> boost/signals/detail/named_slot_map.hpp:130 and
> libs/signals/src/named_slot_map.cpp:27 needs to be increased to <= 1800
> in order to encompass the Visual Studio 2013 Preview compiler.

The "correct" thing to do would be to use 'BOOST_TESTED_AT', i.e.

BOOST_WORKAROUND(BOOST_MSVC, BOOST_TESTED_AT(1700))

This will use the workaround for new versions by default, then when new
compilers are released, outdated tests can be found by using
BOOST_DETECT_OUTDATED_WORKAROUNDS. I'm not sure if anyone actually does
that. It's described in 'boost/detail/workaround.hpp'.

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

Re: Patch bonanza for VS2013 Preview support

Niall Douglas-2
In reply to this post by Lars Viklund
> What's the best way to spend your vacation if not trying to get Boost to
> build on
> bleeding-edge compilers. I set out to see how well Boost 1.54.0 behaved on
> the
> newly released go-live-ready Visual Studio
> 2013 Preview. Below is the list of bugs filed against Boost and Microsoft.
> Enjoy.

Firstly, thanks for the work to support VS2013 so quickly. Much appreciation
from here!

Can I ask: did you switch on the Boost macros for the new C++11 support in
VS2013 to see how those fare? For reference, these are the newly added C++11
features in VS2013 Preview over VS2012:

* Default template arguments for function templates
* Delegating constructors
* Explicit conversion operators
* Initializer lists and uniform initialization
* Raw string literals
* Variadic templates

These are coming in the RTM:

* Alias templates
* Defaulted functions (except for rvalue references v3)
* Deleted functions
* Non-static data member initializers (NSDMIs)
* C99 _Bool
* C99 compound literals
* C99 designated initializers
* C99 variable declarations

Apparently with the new variadic template based STL VS2013 is ~10% faster to
compile and uses ~20% less memory. C++11 support on VS2013 is of course
non-optional, so I guess that's all good for everyone.

Niall

---
Opinions expressed here are my own and do not necessarily represent those of
BlackBerry Inc.


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

smime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Patch bonanza for VS2013 Preview support

Lars Viklund
On Tue, Jul 02, 2013 at 02:53:40PM +0000, Niall Douglas wrote:

> > What's the best way to spend your vacation if not trying to get Boost to
> > build on
> > bleeding-edge compilers. I set out to see how well Boost 1.54.0 behaved on
> > the
> > newly released go-live-ready Visual Studio
> > 2013 Preview. Below is the list of bugs filed against Boost and Microsoft.
> > Enjoy.
>
> Firstly, thanks for the work to support VS2013 so quickly. Much appreciation
> from here!
>
> Can I ask: did you switch on the Boost macros for the new C++11 support in
> VS2013 to see how those fare? For reference, these are the newly added C++11
> features in VS2013 Preview over VS2012:
>
> * Default template arguments for function templates
> * Delegating constructors
> * Explicit conversion operators
> * Initializer lists and uniform initialization
> * Raw string literals
> * Variadic templates

I did not toggle the defect macros for those features as my goal was to
get it into a buildable state as-good-as-predecessor before twiddling
the knobs for the new capabilities.

My own code seems to still build with the small variety of libraries it
includes if I change the condition [1] to not define the defect macros, but
that's not really an exhaustive test.

[1] #if _MSC_FULL_VER < 170051025 || _MSC_FULL_VER < 180020617 && !defined(BOOST_MSVC_ENABLE_2012_NOV_CTP)

Try it and see, I guess. I'd reckon that they will probably cause little
harm, considering that there's people who have tested the Nov12 CTP in
the past.

> These are coming in the RTM:
>
> * Alias templates
> * Defaulted functions (except for rvalue references v3)
> * Deleted functions
> * Non-static data member initializers (NSDMIs)
> * C99 _Bool
> * C99 compound literals
> * C99 designated initializers
> * C99 variable declarations

Speculative definition of features of a non-existing compiler based on
promises is a bit too bold, even for my taste.

--
Lars Viklund | [hidden email]

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

Re: Patch bonanza for VS2013 Preview support

Eric Niebler-4
In reply to this post by Mathias Gaunard-2
On 13-07-02 03:38 AM, Mathias Gaunard wrote:

> On 02/07/13 01:35, Lars Viklund wrote:
>
>> Boost.Signals VS2013 Preview version bump
>> https://svn.boost.org/trac/boost/ticket/8755
>> The BOOST_WORKAROUND macros at
>> boost/signals/detail/named_slot_map.hpp:130 and
>> libs/signals/src/named_slot_map.cpp:27 needs to be increased to <= 1800
>> in order to encompass the Visual Studio 2013 Preview compiler.
>>
>> Boost.MPL VS2013 Preview version bump
>> https://svn.boost.org/trac/boost/ticket/8756
>> The BOOST_WORKAROUND macros at boost/mpl/assert.hpp lines 37 and 247
>> need to be changed to also consider BOOST_MSVC, == 1800, patch attached.
>
> I'm not sure fixing these right now is a good idea, since it's just a
> preview version. The final version will also be 1800, and it might
> behave differently.

I'm in favor of taking these fixes now. If RTM breaks things, we'll
patch it up again.

--
Eric Niebler
Boost.org

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

Re: Patch bonanza for VS2013 Preview support

Niall Douglas-2
In reply to this post by Lars Viklund
> Try it and see, I guess. I'd reckon that they will probably cause little
> harm,
> considering that there's people who have tested the Nov12 CTP in the past.

I will over the coming week: I have quite a bit of Nov12 CTP only #ifdef code,
mainly due to that fun bug where a 'catch(...)' in a template made MSVC try to
expand variadic args. I assume they'll have fixed that.

> > These are coming in the RTM:
> >
> > * Alias templates
> > * Defaulted functions (except for rvalue references v3)
> > * Deleted functions
> > * Non-static data member initializers (NSDMIs)
> > * C99 _Bool
> > * C99 compound literals
> > * C99 designated initializers
> > * C99 variable declarations
>
> Speculative definition of features of a non-existing compiler based on
> promises
> is a bit too bold, even for my taste.
If Microsoft is anything like BlackBerry, those features were committed to the
release branch weeks ago and it's now all in the testing group.

That said, I wouldn't turn them on yet either as a default, but I'd probably
block out the necessary changes for easy enabling later to save time. I would
worry, certainly, that their defaulted functions implementation is quite
incomplete as they point out, sufficiently so it's best to leave it off. The
proof will be in the pudding.

Niall

---
Opinions expressed here are my own and do not necessarily represent those of
BlackBerry Inc.


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

smime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Patch bonanza for VS2013 Preview support

Stephan T. Lavavej-2
[Niall Douglas]
> I will over the coming week: I have quite a bit of Nov12 CTP only #ifdef code,
> mainly due to that fun bug where a 'catch(...)' in a template made MSVC try to
> expand variadic args. I assume they'll have fixed that.

Yes, that was fixed on Nov 28, 2012 (DevDiv#510827 internally).

> If Microsoft is anything like BlackBerry, those features were committed to the
> release branch weeks ago and it's now all in the testing group.

Alias templates and defaulted/deleted functions have been checked into the compiler. I believe the listed C99 features have all been checked in, but I'm not absolutely sure (and presumably they don't matter to Boost). I don't know the current state of NSDMIs as I don't have to take a dependency on them.

I just checked in the STL changes for alias templates; deleted functions are up next.

STL

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

Re: Patch bonanza for VS2013 Preview support

Niall Douglas-2
> > I will over the coming week: I have quite a bit of Nov12 CTP only
> > #ifdef code, mainly due to that fun bug where a 'catch(...)' in a
> > template made MSVC try to expand variadic args. I assume they'll have
> > fixed
> that.
>
> Yes, that was fixed on Nov 28, 2012 (DevDiv#510827 internally).

Outstanding. I'm also very mean to your std::current_exception()
implementation by doing evil such as rethrowing and catching exception_ptr's
caught in other threads during exception catch handling in several hundred
simultaneous threads. GCC and clang get this right, whereas Nov 2012 CTP has
some race conditions in there, and it can and does lose state occasionally if
too many threads are doing this simultaneously.

I didn't report it yet because (a) Nov 2012 CTP isn't production and (b) I'm
hoping to persuade Vicente to add some new member functions to
boost::shared_future<> to let me retrieve the exception_ptr instead of having
to always do a try { future.get(); } catch(...) {
push_back(make_into_boost(std::current_exception()); }. Which obviously takes
much of the load off the exception handling runtime.

> Alias templates and defaulted/deleted functions have been checked into the
> compiler. I believe the listed C99 features have all been checked in, but
> I'm not
> absolutely sure (and presumably they don't matter to Boost). I don't know
> the
> current state of NSDMIs as I don't have to take a dependency on them.
>
> I just checked in the STL changes for alias templates; deleted functions are
> up
> next.
Very useful to know, thanks. I'm sure like most people the killer feature for
me of VS2013 is variadic templates, though the newer C++11 complete Dinkumware
is also a great help. Everything else I can live without for now. You may have
noticed a heated discussion on this very mailing list regarding the topic of
Boost's long term support for compilers such as Visual Studio only recently.

Niall

---
Opinions expressed here are my own and do not necessarily represent those of
BlackBerry Inc.


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

smime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Patch bonanza for VS2013 Preview support

Eric Niebler-4
On 7/3/2013 8:34 AM, Niall Douglas wrote:
> Outstanding. I'm also very mean to your std::current_exception()
> implementation by doing evil such as rethrowing and catching exception_ptr's
> caught in other threads during exception catch handling in several hundred
> simultaneous threads. GCC and clang get this right, whereas Nov 2012 CTP has
> some race conditions in there, and it can and does lose state occasionally if
> too many threads are doing this simultaneously.
>
> I didn't report it yet because [...]
<snip>

Please do. A race condition in the C++ runtime is a *very serious* bug.
I know sometimes it seems like MS isn't listening, but as you can see
from Stephan's involvement here, they clearly do, and it has an effect.

When you file the bug, attach a small program that demonstrates the
problem. And say that it affects Boost. That last bit matters, apparently.

--
Eric Niebler
Boost.org
http://www.boost.org

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

Re: Patch bonanza for VS2013 Preview support

Vicente Botet
In reply to this post by Niall Douglas-2
Le 03/07/13 17:34, Niall Douglas a écrit :
> I didn't report it yet because (a) Nov 2012 CTP isn't production and
> (b) I'm hoping to persuade Vicente to add some new member functions to
> boost::shared_future<> to let me retrieve the exception_ptr instead of
> having to always do a try { future.get(); } catch(...) {
> push_back(make_into_boost(std::current_exception()); }. Which
> obviously takes much of the load off the exception handling runtime.
Hi Niall,

please start a new thread related to your wish.

Best,
Vicente

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

Re: Patch bonanza for VS2013 Preview support

Charles_J_Wilson
In reply to this post by Lars Viklund
I've applied the patch set and built a 1.54.0 and am seeing errors in the filesystem object destructors.

Any idea when someone will be able to stand up a test for this platform?

Charles Wilson
Principal Software Development Engineer
Dell | Enterprise Solutions Group

> -----Original Message-----
> From: Boost [mailto:[hidden email]] On Behalf Of Lars
> Viklund
> Sent: Monday, July 01, 2013 6:36 PM
> To: [hidden email]
> Subject: [boost] Patch bonanza for VS2013 Preview support
>
> Hi list.
>
> What's the best way to spend your vacation if not trying to get Boost to build
> on bleeding-edge compilers. I set out to see how well Boost 1.54.0 behaved
> on the newly released go-live-ready Visual Studio
> 2013 Preview. Below is the list of bugs filed against Boost and Microsoft.
> Enjoy.
>
> With these patches in place, I can get a complete build working with all
> libraries normally available on a fresh machine (means that I didn't test
> Python, MPI, ICU, compressed streams).
>
> I haven't been able to find out how to run the tests in any human-readable
> form, but this should not cause any regressions as it's either increasing
> workaround bounds or adding headers that the standard mandates already.
>
> Boost.Config VS2013 Preview version bump
> https://svn.boost.org/trac/boost/ticket/8753
> The Visual Studio 2013 Preview toolchain has _MSC_VER 1800 and
> _MSC_FULL_VER 180020617. See the attached patch for the minimum
> changes that are needed to get anywhere at all.
>
> Boost.Build needs support for the VS2013 Preview toolset (18.00.20617.1)
> https://svn.boost.org/trac/boost/ticket/8754
> Visual Studio 2013 Preview is out and claims to be 12.0. I copy-pasted
> everything related to 11.0 to refer to 12.0 and it Works On My Machine, see
> attached patch.
>
> Boost.Signals VS2013 Preview version bump
> https://svn.boost.org/trac/boost/ticket/8755
> The BOOST_WORKAROUND macros at
> boost/signals/detail/named_slot_map.hpp:130 and
> libs/signals/src/named_slot_map.cpp:27 needs to be increased to <= 1800 in
> order to encompass the Visual Studio 2013 Preview compiler.
>
> Boost.MPL VS2013 Preview version bump
> https://svn.boost.org/trac/boost/ticket/8756
> The BOOST_WORKAROUND macros at boost/mpl/assert.hpp lines 37 and 247
> need to be changed to also consider BOOST_MSVC, == 1800, patch attached.
>
> Boost.Serialization lacks algorithm header include for std::min
> https://svn.boost.org/trac/boost/ticket/8757
> The <algorithm> header providing std::min is not included in
> boost/archive/iterators/transform_width.hpp, this breaks on Visual Studio
> 2013 Preview due to library changes.
>
> Boost.Asio lacks algorithm header include for std::min
> https://svn.boost.org/trac/boost/ticket/8758
> The <algorithm> header providing std::min is not included in
> boost/asio/detail/impl/win_iocp_io_service.hpp, this breaks on Visual Studio
> 2013 Preview due to library changes.
>
> std::bind broken with boost/tuple/tuple.hpp or anything else providing a ADL
> tie
> https://connect.microsoft.com/VisualStudio/feedback/details/792163/std-
> bind-lack-of-qualifier-on-tie-finds-non-std-tie-by-adl
> Not our fault, I filed a bug on Connect and am hoping that they'll notice it
> before RTM. 'std::bind' finds our 'tie' if a type from a boost namespace is
> used in the 'std::function' argument type list.
>
> --
> Lars Viklund | [hidden email]
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost

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

Re: Patch bonanza for VS2013 Preview support

Niall Douglas-2
In reply to this post by Eric Niebler-4
> On 7/3/2013 8:34 AM, Niall Douglas wrote:
> > Outstanding. I'm also very mean to your std::current_exception()
> > implementation by doing evil such as rethrowing and catching
> > exception_ptr's caught in other threads during exception catch
> > handling in several hundred simultaneous threads. GCC and clang get
> > this right, whereas Nov 2012 CTP has some race conditions in there,
> > and it can and does lose state occasionally if too many threads are
doing this
> simultaneously.
> >
> > I didn't report it yet because [...]
> <snip>
>
> Please do. A race condition in the C++ runtime is a *very serious* bug.
> I know sometimes it seems like MS isn't listening, but as you can see from
> Stephan's involvement here, they clearly do, and it has an effect.

Not at all - every bug I've ever filed to date with Microsoft's compiler
team has been fixed. Some bugs have taken a lot longer than others, but they
have kept the issue tracker up to date with progress and intentions
generally.

> When you file the bug, attach a small program that demonstrates the
problem.
> And say that it affects Boost. That last bit matters, apparently.

Proposed Boost.AFIO isn't in Boost yet. Paul Kirth, the GSoC student doing
most of the labour, has done a great job in converting over the old codebase
into Boost and has been climbing the steep, steep hill which is Boost.Build.
I finally got BoostBook documentation (derived from Boost.Geometry's
machinery) building cleanly to HTML and PDF for the very first time last
night, so I can start into the documentation at long last. I'm also at work
on a cloud based per-commit Jenkins VS2010 unit test slave which will be
followed by a FreeBSD 10 per-commit unit test slave with its shiny and
unique clang + libcxx combo.

End of this month we have our first GSoC report to Google - we hope to have
a functional AFIO library ready for sandbox by the end of this month.
Sometime after that I'll get to reporting bugs we found to their various
sources. After all, the bugs could actually be in our code!

Niall

---
Opinions expressed here are my own and do not necessarily represent those of
BlackBerry Inc.



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

smime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Patch bonanza for VS2013 Preview support

Stephan T. Lavavej-2
[Eric Niebler]
> A race condition in the C++ runtime is a *very serious* bug.

Yeah, seriously. I wasn't aware that exception_ptr was buggy.

[Niall Douglas]
> I didn't report it yet because (a) Nov 2012 CTP isn't production

Argh. The Nov 2012 CTP contained no library changes, so this is almost certainly broken in 2012 RTM (+Update N). In fact, it's probably been broken since 2010 RTM when exception_ptr was first implemented.

Now it's probably too late to fix this in 2013 RTM. Please please please don't sit on bug reports!

(And anyways, the major purpose of CTP/alphas and Preview/betas is to get bug reports.)

> You may have noticed a heated discussion on this very mailing list
> regarding the topic of Boost's long term support for compilers such
> as Visual Studio only recently.

I have the luxury of targeting a single compiler version. Although Boost targets multiple compiler versions, I'd recommend a policy of supporting the current and previous major versions only (excluding pre-RTM major versions). People using old compilers can use old Boosts.

STL


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

Re: Patch bonanza for VS2013 Preview support

Mathias Gaunard-2
On 04/07/13 02:31, Stephan T. Lavavej wrote:

> I have the luxury of targeting a single compiler version. Although Boost targets multiple compiler versions, I'd recommend a policy of supporting the current and previous major versions only (excluding pre-RTM major versions). People using old compilers can use old Boosts.

Some people still have incentive to get all of current Boost to work
with Visual C++ 2008 and up.
I don't think it's a good thing to disregard the community's needs.

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

Re: Patch bonanza for VS2013 Preview support

John Maddock
>> I have the luxury of targeting a single compiler version. Although Boost
>> targets multiple compiler versions, I'd recommend a policy of supporting
>> the current and previous major versions only (excluding pre-RTM major
>> versions). People using old compilers can use old Boosts.
>
> Some people still have incentive to get all of current Boost to work with
> Visual C++ 2008 and up.
> I don't think it's a good thing to disregard the community's needs.

Indeed, and those of us that are still running Vista, are unable to upgrade
to either the 2012 or 13 releases :-(

John.


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

Re: Patch bonanza for VS2013 Preview support

Niall Douglas-2
In reply to this post by Stephan T. Lavavej-2
> > A race condition in the C++ runtime is a *very serious* bug.
>
> Yeah, seriously. I wasn't aware that exception_ptr was buggy.

If I had to take a guess, I'd say it's throw and rethrow semantics during a
deep nesting of try...catch's during which multiple catch handlers are in
flight.

I did, at the time, try setting a flag in the catch handler to invoke
handling outside the try...catch which did work correctly, but broke my code
where I do a particularly evil trick of using throw; as a form of return;
but which invokes the next upper most try...catch handler with the currently
handled exception. I could have added a TLS for the "current" exception and
worked around it that way, but I figured do the Boost port first and figure
it out after.

Before someone suggests it's bad design, I agree it isn't pretty, but I
can't think of a better way to provide exception safety for any arbitrary
completion handler whilst still providing exception state propagation which
is one of the key design tenets of Boost.AFIO (if an asynchronous file i/o
op errors, you really, really want that error to propagate in some instances
to dependent operations otherwise your usage logic becomes hideously complex
to get right i.e. user code becomes very likely to be buggy). I think it's
better to encapsulate the tricky, likely to be buggy code in the library
rather than pushing it onto the user to get right.

> [Niall Douglas]
> > I didn't report it yet because (a) Nov 2012 CTP isn't production
>
> Argh. The Nov 2012 CTP contained no library changes, so this is almost
certainly
> broken in 2012 RTM (+Update N). In fact, it's probably been broken since
2010
> RTM when exception_ptr was first implemented.
>
> Now it's probably too late to fix this in 2013 RTM. Please please please
don't sit
> on bug reports!

I appreciate that. However, the code is not even of beta quality itself yet.
It was originally pure C++11 and therefore taxes C++11 implementation in
novel ways. Once it is fully converted to Boost and is mature enough that I
think it reliable enough for me to draw conclusions from it about other
people's code, then and only then is the right time to start formulating bug
demonstration examples for third party code.

You must appreciate that the proposed library is very heavily multithreaded
and clang's ThreadSanitiser reports multiple possible race conditions, none
of which I have touched yet as there is no point until after the Boost
conversion. In other words, I don't trust my code yet.

> > You may have noticed a heated discussion on this very mailing list
> > regarding the topic of Boost's long term support for compilers such as
> > Visual Studio only recently.
>
> I have the luxury of targeting a single compiler version. Although Boost
targets
> multiple compiler versions, I'd recommend a policy of supporting the
current and
> previous major versions only (excluding pre-RTM major versions). People
using
> old compilers can use old Boosts.

As VS2010 is the last VS which will run on Windows XP, we've decided that we
will target VS2010 as our absolute minimum. That will give us support of the
last three major Visual Studio releases which hopefully will satisfy Boost's
portability requirement, even though C++03 compatibility is gone.

Additionally it greatly helps setting up the cloud per-commit unit test
slaves if we can use Windows XP. Windows 7 is RAM hungry, Windows 8 is too
expensive for a unit test slave, and I have an old spare licence for Windows
XP. Seeing as all this test infrastructure is being funded by my personal
pocket, these matters are important.

Niall

---
Opinions expressed here are my own and do not necessarily represent those of
BlackBerry Inc.



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

smime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Patch bonanza for VS2013 Preview support

Eric Niebler-4
On 7/4/2013 8:50 AM, Niall Douglas wrote:

> [Stephan T. Lavavej]:
>> Now it's probably too late to fix this in 2013 RTM. Please please
>> please don't sit on bug reports!
>
> I appreciate that. However, the code is not even of beta quality
> itself yet. It was originally pure C++11 and therefore taxes C++11
> implementation in novel ways. Once it is fully converted to Boost
> and is mature enough that I think it reliable enough for me to draw
> conclusions from it about other people's code, then and only then is
> the right time to start formulating bug demonstration examples for
> third party code.

I don't understand your
"my-code-is-imperfect-so-third-party-libraries-are-blameless" attitude.
The time to file a bug is when you find it. Even when writing throw-away
or pre-alpha code, when I see something that isn't right, I create a
scratch project and try to reproduce it. Then I file the bug and get on
with my work. Often, even before my pre-alpha project has matured, the
bug has been fixed and I can remove my workaround. That's how it should
work.

--
Eric Niebler
Boost.org
http://www.boost.org

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