Subject: [Boost-bugs] [Boost C++ Libraries] #4072: [result_of] decltype-based implementation breaking valid code on msvc-10
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2010-04-05 22:36:32
#4072: [result_of] decltype-based implementation breaking valid code on msvc-10
----------------------------------------+-----------------------------------
Reporter: eric_niebler | Owner: dgregor
Type: Bugs | Status: new
Milestone: Boost 1.43.0 | Component: utility
Version: Boost Release Branch | Severity: Problem
Keywords: decltype result_of msvc-10 |
----------------------------------------+-----------------------------------
I recently looked into some proto failures on msvc-10 and traced them back
to the use of decltype in the implementation of boost::result_of. The
program below demonstrates the problem:
{{{
// Uncomment the next line to make the problem go away
//#define BOOST_NO_DECLTYPE
#include <boost/utility/result_of.hpp>
template<class X, class Y> struct pair {};
template<class Base>
struct S;
struct wrapper
{
template<class T>
struct result;
template<class This, typename That>
struct result<This(That)>
{
typedef S<That> type;
};
template<typename That>
typename result<wrapper(That)>::type
operator()(That) const
{
return 0;
}
};
template<class T>
struct S
{
S(int = 0) {}
typename boost::result_of<wrapper(pair<T, T>)>::type foo()
{
return 0;
}
};
int main()
{
S<int> s;
}
}}}
The use of decltype in result_of causes the compiler to recursively
instantiate templates until it blows its stack. To make the problem go
away, you must #define BOOST_NO_DECLTYPE.
I suspect the real problem is in a buggy implementation of decltype on
msvc-10. For the upcoming boost release, I suggest that we stick with the
non-decltype implementation of result_of on msvc-10, or risk massively
breaking users' code, not to mention proto, spirit and xpressive on that
compiler.
-- Ticket URL: <https://svn.boost.org/trac/boost/ticket/4072> Boost C++ Libraries <http://www.boost.org/> Boost provides free peer-reviewed portable C++ source libraries.
This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:02 UTC