Eric Niebler <eric@boostpro.com> writes:
John Maddock wrote:
Beman Dawes wrote:
Eric Niebler wrote:
What that means for Boost.Config is unclear to me. We may decide to define a defect macro for this particular buggy decltype behavior, since gcc's decltytpe works this way, too.
That sounds like a reasonable approach. Care to propose a name? What is the CWG issue number?
If all compilers decltype implementations have this issue, *and* it is currently std conforming, then maybe we shouldn't have a defect macro at all? Or at least wait until we know whether this is likely to be fixed in the std?
Just my 2c, John.
Oh. Yeah, that sounds better. And it seems to me that VC10's decltype probably works well enough to leave BOOST_NO_DECLTYPE undefined, but I'd see some more examples of code in the wild that would be broken by the bug Anthony is referring to.
I found the bug when trying to use a decltype-based result_of on a function returning a class with a user-defined default constructor. I'll try and find some other examples. Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976