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 | zao@acc.umu.se

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 | zao@acc.umu.se

[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

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

[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

...

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.

...

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.

...

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.

In your opinion sure, and if your code quality is anything like your C++ Now presentation then I think you're entirely right to take that approach. You may remember me congratulating you on that use of a volatile member function overload as part of useful template error reporting, something I had never previously thought of to combine with the virtual trick. My code, on the other hand, I don't trust and I assume it to be riddled with severe bugs which I'm too incompetent to perceive. This isn't a humility thing, it's an empirical thing: I have had showstopping bugs found in my open source *four* *years* after that code went stable and was being used in anger by banks, hedge funds, the US DoD for military simulations, automotive and avionics. And I had worked on that code for four years thereafter, and never saw nor found those problems not once in that time period. To which the only natural conclusion must be that I was, and am, too incompetent to find these things on my own. Hence my hesitancy to cast aspersions on others. Once the code base is stable and fully ported to Boost, then I'm happy to start work on a clean ThreadSanitiser during which I'll no doubt discover and fix a ton of problems in my code. Only then will I feel comfortable in blaming others for problems I have found. Niall --- Opinions expressed here are my own and do not necessarily represent those of BlackBerry Inc.

...

To which the only natural conclusion must be that I was, and am, too incompetent to find these things on my own. Hence my hesitancy to cast aspersions on others. Once the code base is stable and fully ported to Boost, then I'm happy to start work on a clean ThreadSanitiser during which I'll no doubt discover and fix a ton of problems in my code. Only then will I feel comfortable in blaming others for problems I have found.

So you're afraid to file a bug report only to be told the bug is in your code or in your understanding? This happens to me ALL THE TIME. I regularly get schooled by Richard Smith, who closes about half my clang bugs as "by design". Doesn't stop me. Better to make an erroneous report than to sit on it.

Heh! I would have said that I don't want to waste other people's valuable time until I'm sure the problem is in their code and not mine. Usually my intuitions about the cause of a bug are correct, but that's not the same as empirical proof.

I seem to be unable to change your opinion, so I'll stop now. <shrug> But it should be telling that even a representative of a compiler vector (Stephan) is begging you to file the bug.

We don't disagree on anything except timing - you think bug reports should come sooner, I think they should come later. We're actually only talking two months difference at most considering GSoC ends in September. Note that if the bug were in the compiler frontend, the report would go in instantly because then it can't be my code. And you're right that in 50% of the cases I've reported those I've also been told the compiler's behavior is by design. The C++ language spec is huge. Niall --- Opinions expressed here are my own and do not necessarily represent those of BlackBerry Inc.

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

[Niall Douglas]

Agreed, VS2013 Preview's new C++11 features are looking solid.

Yay!

Apart from http://connect.microsoft.com/VisualStudio/feedback/details/794707/sfinae-fai lure-during-variadic-template-overload-resolution which is a showstopper for us that is.

That's actually a library issue, not a compiler issue. You're expecting C++14's SFINAE-friendly result_of, but you're getting C++11's SFINAE-hostile result_of. (That's in addition to the fact that our result_of/<functional> implementation has numerous bugs with respect to C++11.) Unfortunately, I won't be able to fix this in 2013 RTM. result_of needs to be thoroughly overhauled, but I'm not allowed to make such a major change at this point. I should be able to do this for the next major version, though. As an aside, why is Boost using std::result_of anyways? You've got Eric Niebler and his SFINAE-friendly boost::result_of, you know. :-> STL

[Niall Douglas]

You've done well, though I have to say that so far at least the Preview feels slightly rough around the edges. For example, when working with Boost with all its available C++11 turned on, I'm seeing repeated errors from the linker of this form: fatal error C1128: number of sections exceeded object file format limit : compile with /bigobj ... and recompiling Boost with /bigobj for every compiland does indeed do the trick. This didn't happen with Nov 2012 CTP though. Have any other Boosters seen the same problem? Is /bigobj going to have to be made default on for all Boost?

According to my understanding, this happens when you emit more than 64k functions. The compiler really should enable /bigobj by default (or at least automagically) but for historical reasons it doesn't.

I'm unclear why this is a C++14 issue. Nov 2012 CTP didn't have this problem.

I'd have to investigate to figure out exactly what happened, but we changed result_of between 2012 and 2013.

I also think you haven't looked at the bug closely enough - I'm *not* calling result_of<> in the way you think.

Hmm. VC rejects this code: C:\Temp>type purr.cpp template <typename T> struct NoCharsAllowed { static_assert(sizeof(T) > 1, "No chars allowed!"); }; template <typename A> void purr(int, const A&); template typename NoCharsAllowed<B>::type purr(void *, const B&, Types...); int main() { purr(1729, 'x'); } C:\Temp>cl /EHsc /nologo /W4 /c purr.cpp purr.cpp purr.cpp(2) : error C2338: No chars allowed! purr.cpp(10) : see reference to class template instantiation 'NoCharsAllowed<char>' being compiled However, GCC accepts it, contrary to my understanding of the Standard. My brain tells me that template argument deduction should run for the B overload even though it will ultimately be nonviable (because 1729 isn't convertible to void *). It also tells me that if it runs, the static_assert should really explode and not trigger SFINAE. Either GCC is wrong, or one of these parts of my mental model is wrong. I'll ask our compiler team.

AFIO by default uses the C++ standard library where possible, and Boost equivalents where not possible. The choice can be overridden at compile time of course.

Ok, that makes sense. Thanks, STL

[Niall Douglas]

I might add that seeing as VS2012 doesn't output binaries which will execute on pre-Vista

2012 Update 3 supports XP targeting.

BTW, in your later post you mention clang won't compile the above. As clang does compile my call() test case, I take it that result_of<> in libstdc++ and libcxx are the SFINAE friendly variants you mentioned?

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3462.html says: "Implementation Experience Has this been implemented yet? Yes. In c++std-lib-33002, Howard Hinnant claims that his libc++ library has already shipped a SFINAE-friendly result_of. In c++std-lib-33013, he links to his implementation. It can be found at http://llvm.org/svn/llvm-project/libcxx/trunk/include/type_traits. Daniel Krügler claimed in a private exchange to have recently implemented a SFINAE-friendly result_of for gcc. Also, Boost recently switched to a SFINAE-friendly result_of, although it hasn't shipped it yet at the time of writing (2012-09-20)."

If so then arse, because for VS2013 I'm going to have to make a special exception just for that compiler version alone to use boost::result_of<>.

You might want to do that for 2012 and earlier too, where std::result_of didn't work for movable-only arguments. STL

More curiously (according to our compiler team; I haven't run clang myself):

VC 2013: static_assert GCC 4.8.1: accepts EDG 4.6: accepts clang 3.3: static_assert

A clang developer has recently pointed me to an interesting clause in the standard ([temp.inst] p6): "If the overload resolution process can determine the correct function to call without instantiating a class template definition, it is unspecified whether that instantiation actually takes place." Perhaps this is coming into play here (and thus all of the above behaviour is standard-conforming)? Regards, Nate

[Nathan Ridge]

...

A clang developer has recently pointed me to an interesting clause in the standard ([temp.inst] p6): "If the overload resolution process can determine the correct function to call without instantiating a class template definition, it is unspecified whether that instantiation actually takes place." Perhaps this is coming into play here (and thus all of the above behaviour is standard-conforming)?

That's an excellent catch. Yep, I agree.

Of course, just because there isn't a unique standard-conforming behaviour doesn't mean that isn't value in compiler implementers agreeing on a de facto standard behaviour in common cases, like the one that arose in this thread. :) Regards, Nate