...

* Remove the concept related macros. * Tighten up most of the C++0x related tests, with the result that some C++0x features that were previously enabled are no longer - this may also cause the Boost.Config tests to fail on some platforms. * Some C++0x features that were not previously enabled are now - because they were passing the Boost.Config tests - there's at least one case where this is causing regressions in other libraries - if any more pop up please let me know ASAP!

Any reason why decltype on MSVC10 is still not enabled?

If someone tells me that this issue: http://lists.boost.org/Archives/boost/2010/04/164645.php is fixed then fine, otherwise it appears to be a lot trouble, John.

On 3/16/2011 12:45 PM, Mathias Gaunard wrote:

On 16/03/2011 19:39, John Maddock wrote:

...

...

...

* Remove the concept related macros. * Tighten up most of the C++0x related tests, with the result that some C++0x features that were previously enabled are no longer - this may also cause the Boost.Config tests to fail on some platforms. * Some C++0x features that were not previously enabled are now - because they were passing the Boost.Config tests - there's at least one case where this is causing regressions in other libraries - if any more pop up please let me know ASAP!

Any reason why decltype on MSVC10 is still not enabled?

If someone tells me that this issue: http://lists.boost.org/Archives/boost/2010/04/164645.php is fixed then fine, otherwise it appears to be a lot trouble,

I wasn't aware of this issue. But doesn't it only affect result_of, with decltype still usable in practice for other things?

Some. The VS2010 compiler's decltype implementation gets a lot of things wrong though. It'll result in "T const" rather than "T" when used in auto returns and it gets function types wrong. I can't at the moment immediately think of the exact reproduction steps but I do know that decltype as implemented by 2010 is pretty far from being compliant. I still use it but every once in a while run into its issues.

On 3/16/2011 1:53 PM, Stephan T. Lavavej wrote:

[Noah Roberts]

...

The VS2010 compiler's decltype implementation gets a lot of things wrong though. It'll result in "T const" rather than "T" when used in auto returns and it gets function types wrong. I can't at the moment immediately think of the exact reproduction steps but I do know that decltype as implemented by 2010 is pretty far from being compliant. I still use it but every once in a while run into its issues.

Please report such bugs through Microsoft Connect instead of suffering in silence. If they affect you as a Boost developer or Boost user, please explain that too - it helps us to understand the impact of a bug.

Obviously we try to find and fix bugs ourselves, but submitting bug reports helps us help you. :->

I tried that route as have several others. Official response was, "We know, suck it." Maybe they'll fix it in the next version, but they've known that decltype had problems before they released 2010 and even in SP1 it's not on the list of fixes. Maybe it is fixed in SP1, I haven't applied the patch yet (since the 2005 SP1 screwed us hard we now test things out before going forward and haven't had the chance).

On Thu, Mar 17, 2011 at 12:51 PM, Eric Niebler <eric@boostpro.com> wrote:

On 3/17/2011 11:29 PM, Noah Roberts wrote:

...

On 3/16/2011 1:53 PM, Stephan T. Lavavej wrote:

...

Please report such bugs through Microsoft Connect instead of suffering in silence. If they affect you as a Boost developer or Boost user, please explain that too - it helps us to understand the impact of a bug.

Obviously we try to find and fix bugs ourselves, but submitting bug reports helps us help you. :->

I tried that route as have several others.  Official response was, "We know, suck it." <snip>

Haha! And hear hear! Stephan, I frequently file bugs through the Connect website. Sometimes I wonder why because almost without exception they're closed "Won't Fix".

Ditto. I've had the same experience. http://connect.microsoft.com/VisualStudio/feedback/details/571720/c-use-of-m... <snip>

A humble suggestion: issue compiler patches out of band. And if you're going to ask people to file bugs, fix them.

+1 Daniel Walker

Michael Fawcett wrote on Thursday, March 17, 2011 2:13 PM

Pot meet kettle? Boost has the same issues, in fact 1.46.1 is the first point release in a long time, even when it was desperately needed in the past. It has tickets that languish for years in Trac. Stephan seems to stay up to date with this list and seems to genuinely try to better Visual Studio. I can't see why he is being piled on.

Just my experience, but Boost feels to me to be quite responsive. It's released frequently, and with the next just a month or two away, I never have to wait long for improvements. The few times that I've run into bugs that I couldn't wait for, I had no trouble finding someone that I could send my fixes to and getting into the release. All this for free from people who volunteer their time for free. Erik ---------------------------------------------------------------------- This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses. References to "Sender" are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing.

On 3/17/2011 11:13 AM, Michael Fawcett wrote:

On Thu, Mar 17, 2011 at 1:16 PM, Daniel Walker <daniel.j.walker@gmail.com> wrote:

...

On Thu, Mar 17, 2011 at 12:51 PM, Eric Niebler<eric@boostpro.com> wrote:

...

On 3/17/2011 11:29 PM, Noah Roberts wrote:

...

On 3/16/2011 1:53 PM, Stephan T. Lavavej wrote:

...

Please report such bugs through Microsoft Connect instead of suffering in silence. If they affect you as a Boost developer or Boost user, please explain that too - it helps us to understand the impact of a bug.

Obviously we try to find and fix bugs ourselves, but submitting bug reports helps us help you. :->

I tried that route as have several others. Official response was, "We know, suck it." <snip>

Haha! And hear hear! Stephan, I frequently file bugs through the Connect website. Sometimes I wonder why because almost without exception they're closed "Won't Fix".

Ditto. I've had the same experience.

http://connect.microsoft.com/VisualStudio/feedback/details/571720/c-use-of-m...

This seems like an entirely reasonable response. I've heard similar responses from Boost Release Managers on this mailing list.

...

...

A humble suggestion: issue compiler patches out of band. And if you're going to ask people to file bugs, fix them.

+1

Pot meet kettle? Boost has the same issues, in fact 1.46.1 is the first point release in a long time, even when it was desperately needed in the past. It has tickets that languish for years in Trac. Stephan seems to stay up to date with this list and seems to genuinely try to better Visual Studio. I can't see why he is being piled on.

Well, I for one wasn't piling on anyone. I was simply mentioning some facts about decltype in 2010 having bugs as a possible reason why some boost authors might not want to rely on it. I didn't even realize Stephan was a part of the MS group when I replied to his suggestion to post a bug, I was simply stating that it had been done albeit with some frustration. The fact that I and other MS users don't exactly feel listened to is probably not something he can do anything about. As a professional developer I can understand triage. Being told to submit a bug when you already did and where told it was a known, non-fix issue though is mildly frustrating and I responded in some jest (though I do sometimes get the feeling "suck it, we know you have to use it anyway" is the MS-mantra). Certainly wasn't trying to single anyone out for blame or abuse. What bugs get fixed is usually guided more by what users will put up with than what the developers think is important anyway, as we're probably all very aware.

On Fri, Mar 18, 2011 at 8:45 AM, Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:

On 17/03/2011 19:13, Michael Fawcett wrote:

...

Pot meet kettle?  Boost has the same issues, in fact 1.46.1 is the first point release in a long time, even when it was desperately needed in the past.  It has tickets that languish for years in Trac.

It's less important for Boost, since the code is publically available and anyone can easily patch it.

I'm an advocate of open source and glad that that possibility exists.

Also most problems are fixed in trunk quickly (and again, trunk is publically available), but get into releases sometimes quite late. That's because the way Boost does releases is fairly broken; this is a known controversial issue that may eventually get fixed in the future.

Bugs are not closed wontfix, they're just not solved. That's because sometimes there is no active maintainer for that piece of code; unlike a company, boost developers do this in their spare time, and sometimes they don't have time to spare.

So honestly I don't see how you can say that Boost suffers from the same problems as the Visual C++ team.

And honestly I don't see how just because the reasons differ you think the end result is any different to an end user. --Michael Fawcett

Any reason why decltype on MSVC10 is still not enabled?

[John Maddock]

If someone tells me that this issue: http://lists.boost.org/Archives/boost/2010/04/164645.php is fixed then fine, otherwise it appears to be a lot trouble,

Is this the same issue as http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3233.html ? Stephan T. Lavavej Visual C++ Libraries Developer

Yes. So the behavior of vc10's decltype wrt this issue is in conformance with /current/ working paper -- which is broken, according to n3233. It will be discussed soon in Madrid. If the proposed wording is accepted (and I hope to god it is), then VC10's decltype --along with everybody else's-- will need to be fixed.

But please fix it anyway. :-)

Eric, is it still your opinion that enabling decltype for vc-10 in Boost.Config will break too much for it to be worth it? Thanks, John.

...

...

Yes. So the behavior of vc10's decltype wrt this issue is in conformance with /current/ working paper -- which is broken, according to n3233. It will be discussed soon in Madrid. If the proposed wording is accepted (and I hope to god it is), then VC10's decltype --along with everybody else's-- will need to be fixed.

But please fix it anyway. :-)

Eric, is it still your opinion that enabling decltype for vc-10 in Boost.Config will break too much for it to be worth it?

I worked around the problem in Proto, so Proto and its dependencies should be ok -- so flip it, right? OTOH, we flip it, then users' code could break the way Proto did -- so don't flip it, right? OTOH, if n3233 gets rejected, then our hand is forced: vc10's decltype is strictly conforming, even if it breaks stuff -- so why not just flip it now, right? I've run out of hands, and I haven't seen a good option yet.

Sure, yeah, what the hell, flip the switch on trunk and see what breaks. Whee!

OK, enabled, fingers crossed and hopes for the best... John.

On 18/03/2011 01:35, Stephan T. Lavavej wrote:

[Eric Niebler]

...

Yes. So the behavior of vc10's decltype wrt this issue is in conformance with /current/ working paper -- which is broken, according to n3233. It will be discussed soon in Madrid. If the proposed wording is accepted (and I hope to god it is), then VC10's decltype --along with everybody else's-- will need to be fixed. But please fix it anyway. :-)

I'll ask the compiler team for a fix. I don't always get what I want, but the STL is the compiler's first and best customer, and I've been looking forward to making result_of 95% powered by decltype.

(Keeping track of rvalue references v2, lambdas v1.1, rvalue references v2.1, rvalue references v3 - I actually don't know if that one was reverted in the Working Paper - and now decltype v1.1 can be exhausting!)

MSVC also has a lot of bugs with function types in general, which can affect result_of, function, or other similar things negatively. Here is one bug: https://connect.microsoft.com/VisualStudio/feedback/details/282942/syntax-er... Here is a testcase of another bug that causes an error in result_of: void foo(int) {} struct bar_t { template<typename Sig> struct result; template<typename This, typename F> struct result<This(F)> { typedef void type; }; template<typename F> void operator()(const F&) const { } }; template<typename F> typename std::tr1::result_of<bar_t(const F&)>::type bar(const F& f) { bar_t b; return b(f); } void call_foo() { bar(foo); } This fails with an error message in _Remove_reference called by _Result_of. Changing it to bar(&foo) allows to work around the problem though.

On 3/18/2011 3:36 PM, Stephan T. Lavavej wrote:

[Mathias Gaunard]

...

Here is a testcase of another bug that causes an error in result_of: This fails with an error message in _Remove_reference called by _Result_of.

I've verified that this fails to compile with VC10 RTM/SP1 and successfully compiles with my current build of VC11:

C:\Temp>type meow.cpp #include<functional>

void foo(int) { }

struct bar_t { template<typename Sig> struct result;

template<typename This, typename F> struct result<This(F)> { typedef void type; };

template<typename F> void operator()(const F&) const { } };

template<typename F> typename std::result_of<bar_t(const F&)>::type bar(const F& f) { bar_t b; return b(f); }

void call_foo() { bar(foo); }

C:\Temp>cl Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 17.00.40316 for 80x86 Copyright (C) Microsoft Corporation. All rights reserved.

usage: cl [ option... ] filename... [ /link linkoption... ]

C:\Temp>cl /EHsc /nologo /W4 /c meow.cpp meow.cpp

C:\Temp>

John Maddock reported a bunch of type traits bugs to us, which I filed as the "Consolidated Omnibus Type Traits Bug of 2010", and we fixed them all. (Most of them were library bugs, but a couple were compiler bugs, as I recall.)

If you don't like Connect, you can report C++ Standard Library bugs directly to me. My capacity to fix bugs isn't *infinite* (more like exponentially reallocating), but I'll do my best.

Like Eric, I have reported numerous C++ ( and C++/CLI ) issues to Microsoft over the years, and particularly since .Net in 2001, which Microsoft will not fix as long as some workaround exists. While I appreciate the fact that Microsoft will indeed look for a workaround if you ask them, the fact that these C++ bugs continue unfixed release after release simply means that it is more likely that C++ programmers will run into them eventually, and then have to waste their time and efforts finding the workaround rather than doing constructive programming. I have my doubts whether this same approach is taken with C# and VB Net. I don't know who the "us" is to whom John Maddock reported his type trait bugs and I do not know what you mean by "C++ standard library bugs". Care to explain ?

I don't know who the "us" is to whom John Maddock reported his type trait bugs and I do not know what you mean by "C++ standard library bugs". Care to explain ?

I filed the bugs that effected the standard library (type_traits) directly to Stephan via email. John.

On Wed, Mar 23, 2011 at 12:42 PM, Eric Niebler <eric@boostpro.com> wrote:

On 3/18/2011 7:35 AM, Stephan T. Lavavej wrote:

...

[Eric Niebler]

...

Yes. So the behavior of vc10's decltype wrt this issue is in conformance with /current/ working paper -- which is broken, according to n3233. It will be discussed soon in Madrid. If the proposed wording is accepted (and I hope to god it is), then VC10's decltype --along with everybody else's-- will need to be fixed. But please fix it anyway. :-)

I'll ask the compiler team for a fix. I don't always get what I want, but the STL is the compiler's first and best customer, and I've been looking forward to making result_of 95% powered by decltype.

(Keeping track of rvalue references v2, lambdas v1.1, rvalue references v2.1, rvalue references v3 - I actually don't know if that one was reverted in the Working Paper - and now decltype v1.1 can be exhausting!)

And just to keep everybody abreast, N3233 was moved to "immediately ready" in Madrid today, with fairly minor wording tweaks. That means two things, one good and one bad:

Bad: Every decltype implementation is broken. Good: Once they're fixed, we'll have a decltype-based result_of that actually works.

I, for one, am euphoric and would like to thanks James Widman and Doug Gregor for helping to make this happen. Getting the committee to make *any* changes at this point is a major accomplishment.

That's good news! I'm glad you guys pushed for this. Congratulations!

It means one other thing: we should have a config macro for detecting this standards-related decltype bug, because several major compilers have now shipped with it, and I'll need the macro in Proto. I suggest:

 BOOST_NO_DECLTYPE_N3276

(N3276 will be the number of the redrafted N3233.) I can provide a config test for this.

Good idea. Daniel Walker

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/24/2011 9:31 AM, Stephan T. Lavavej wrote:

[Eric Niebler]

...

N3233 was moved to "immediately ready" in Madrid today, with fairly minor wording tweaks.

Awesome! I've filed DevDiv#166326 "N3233: decltype v1.1" in our internal bug database, asking the compiler team to implement this. <snip>

Stephan, be sure in the bug report to point the developers to (the yet to be published) N3276, and not to N3233. The new paper should have the tweaked wording. Or you could just ask James Widman directly. Thanks! Now if only we could get this before VC11... ;-) - -- Eric Niebler BoostPro Computing http://www.boostpro.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNlLd3AAoJEAeJsEDfjLbXgOkH/RiAliZo6Z/bduOlG459FGN6 Wcm3O59Qc2yBlPVBaLLJro02EsIvtSygm69UaBuhEzpcSUxZ7HBQst/OG6cSf9oE /jBJ8lG3OQkqITpRkD7Kp8s8MZoqitllKXUQddNk9rwkYCNB4yNsVqXdspdOdtR8 c0BXkRT7Yevl6puNMgfsN1B3Kysq4GsEtk6zPmj5DMKSnu+fXpMfKUyfyfnt30Y+ PNHb59qWUkLnDsEz+FYHxfe2XACUhGJekh4DZetx4qt76a5LjY09SDcf8xLG82S3 ZPIlMNG9RXDBwOWM41mg0IWXDIV1NjE4zCAgaz01uzJjWF6AyY7x1qWxUiGPo7Y= =kumN -----END PGP SIGNATURE-----

It means one other thing: we should have a config macro for detecting this standards-related decltype bug, because several major compilers have now shipped with it, and I'll need the macro in Proto. I suggest:

BOOST_NO_DECLTYPE_N3276

(N3276 will be the number of the redrafted N3233.) I can provide a config test for this.

By all means if you can provide the necessary test case. John.