(CC'ing Doug, who has the unfortunate distinction of having his name in result_of.hpp.) Has anybody else noticed inexplicable compile failures with MSVC 7.1, and sometimes even MSVC 8.0, when using boost::result_of? It happens with functors that have a nested result<> template, like struct unary { template<typename Sig> struct result; template<typename This, typename Arg> struct result<This(Arg)> { typedef void type; }; ... }; And when instantiating boost::result_of<unary(int)>::type, I'll sometimes get an error like: "struct unary::result<F> is undefined, with F=unary(int)." In some contexts, it seems, MSVC is unable to find the correct partial specialization. The same code will compile fine with GCC. I have yet to find a suitable work-around. As my work relies more and more heavily on result_of, this has become a real pain point for me. I can provide a repro to anybody interested, but it's large so I can't post it here. I haven't found a simple repro yet. -- Eric Niebler Boost Consulting www.boost-consulting.com
Eric Niebler wrote:
(CC'ing Doug, who has the unfortunate distinction of having his name in result_of.hpp.)
Has anybody else noticed inexplicable compile failures with MSVC 7.1, and sometimes even MSVC 8.0, when using boost::result_of?
<snip> And for any enterprising soul who wants to look into this, I attached a repro to the bug at http://tinyurl.com/ymu63z. Seems like a pretty straightforward use of boost::result_of that fails to compile on vc7.1 and vc8. -- Eric Niebler Boost Consulting www.boost-consulting.com
I don't suppose it's the same problem as I was seeing here is it? http://article.gmane.org/gmane.comp.lib.boost.user/14256 I ended up giving up with result_of assuming I must be misunderstanding something as I never got any response. Richard.
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Eric Niebler Sent: 31 October 2006 00:53 To: boost@lists.boost.org Cc: Doug Gregor Subject: Re: [boost] [result_of] problems on MSVC
Eric Niebler wrote:
(CC'ing Doug, who has the unfortunate distinction of having his name in result_of.hpp.)
Has anybody else noticed inexplicable compile failures with MSVC 7.1, and sometimes even MSVC 8.0, when using boost::result_of?
<snip>
And for any enterprising soul who wants to look into this, I attached a repro to the bug at http://tinyurl.com/ymu63z. Seems like a pretty straightforward use of boost::result_of that fails to compile on vc7.1 and vc8.
-- Eric Niebler Boost Consulting www.boost-consulting.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Richard Crossley wrote:
Eric Niebler wrote:
(CC'ing Doug, who has the unfortunate distinction of having his name in result_of.hpp.)
Has anybody else noticed inexplicable compile failures with MSVC 7.1, and sometimes even MSVC 8.0, when using boost::result_of? <snip>
And for any enterprising soul who wants to look into this, I attached a repro to the bug at http://tinyurl.com/ymu63z. Seems like a pretty straightforward use of boost::result_of that fails to compile on vc7.1 and vc8.
I don't suppose it's the same problem as I was seeing here is it?
http://article.gmane.org/gmane.comp.lib.boost.user/14256
I ended up giving up with result_of assuming I must be misunderstanding something as I never got any response.
It appears to be the same issue. I added your much simpler test case to the bug report. Thanks. Sadly, giving up on result_of is not really an option -- it's standard, now. I hope we can find a work-around. -- Eric Niebler Boost Consulting www.boost-consulting.com
Eric Niebler wrote:
Richard Crossley wrote:
http://article.gmane.org/gmane.comp.lib.boost.user/14256
I ended up giving up with result_of assuming I must be misunderstanding something as I never got any response.
It appears to be the same issue. I added your much simpler test case to the bug report. Thanks. Sadly, giving up on result_of is not really an option -- it's standard, now. I hope we can find a work-around.
Ah-ha! I've found a work-around for this problem. If you have code like this: template<typename T> struct Foo { template<typename Sig> struct result; template<typename This, typename A> struct result<This(A)> { typedef A type; }; ... } ... you must transform it into something like this: template<typename T> struct msvc_Foo_result { template<typename Sig> struct result; template<typename This, typename A> struct result<This(A)> { typedef A type; }; }; template<typename T> struct Foo : msvc_Foo_result<T> { ... }; Then you can do result_of<Foo<int>(float)>::type, and MSVC is happy. It only appears to be a problem when Foo is a template. MSVC won't deduce This to be Foo<int> within the Foo template itself, but it WILL deduce This to be Foo<int> in msvc_Foo_result<int>. Go figure. -- Eric Niebler Boost Consulting www.boost-consulting.com
Eric Niebler wrote:
Eric Niebler wrote:
Richard Crossley wrote:
http://article.gmane.org/gmane.comp.lib.boost.user/14256
I ended up giving up with result_of assuming I must be misunderstanding something as I never got any response.
It appears to be the same issue. I added your much simpler test case to the bug report. Thanks. Sadly, giving up on result_of is not really an option -- it's standard, now. I hope we can find a work-around.
Ah-ha! I've found a work-around for this problem. If you have code like this:
template<typename T> struct Foo { template<typename Sig> struct result; template<typename This, typename A> struct result<This(A)> { typedef A type; }; ... }
<snip> Another work-around is to add the following: #if BOOST_WORKAROUND(BOOST_MSVC, BOOST_TESTED_AT(1400)) namespace boost { template<typename T> struct result_of; template<typename T, typename A> struct result_of<Foo<T>(A)> : Foo<T>::template result<void(A)> {}; } #endif This works without forcing you to add a bogus base class, which is handy if you want Foo<T> to be POD. -- Eric Niebler Boost Consulting www.boost-consulting.com
Eric Niebler wrote:
Another work-around is to add the following:
#if BOOST_WORKAROUND(BOOST_MSVC, BOOST_TESTED_AT(1400)) namespace boost { template<typename T> struct result_of;
template<typename T, typename A> struct result_of<Foo<T>(A)> : Foo<T>::template result<void(A)> {}; } #endif
It's also possible to provide the actual return type in the result_of specialization (which is what I use when I need to talk to result_of). No workarounds are needed in this case. template<class T, class A> struct result_of<Foo<T>(A)> { typedef ... type; }; The problem is that to stay cv-correct you need four specializations. Two if you ignore volatile function objects. template<class T, class A> struct result_of<Foo<T> const ( A )> { typedef ... type; };
participants (3)
-
Eric Niebler -
Peter Dimov -
Richard Crossley