From: shunsuke (pstade.mb_at_[hidden])
Date: 2007-03-22 18:11:05
Daniel Walker wrote:
> I would be perfectly happy using your <boost/lambda/result_of.hpp> for
> the nullary case alone, if we moved it to
> <boost/lambda/detail/result_of.hpp> and had the boost/lambda/* headers
> include it so that lambda/result_of interoperability was transparent
> to the user. That combined with the lambda patch would probably
I don't recommand the way to include implicitly.
It would actually break codes written by the author
of http://tinyurl.com/2xw4s2 , which is not mine.
IMO, it should be separated, following Boost.Typeof way.
>> If user workarounds of sig-compatible functor users cannot be removed,
>> that patch loses the original intention?
> I'm not sure if I fully understand your question, but the patch
> doesn't lose the original intent entirely. Users can still use nary
> sig-compatible functors, which they couldn't use before. (However, as
> I stated above, it would be convenient but I'm not sure that it's
> necessary for result_of to support the current sig convention.) Lambda
> users are in the same boat as people writing result-compatible
> functors when it comes to nullary calls. They need to write a
> specialization of result_of for when their functor is called with no
> arguments. result_of doesn't attempt to automatically deduce the type,
> although it could with has_template_xxx.
After all, this seems to depend on the functionality
and portability of has_template_xxx.
I hope it will work under VC++.
-- Shunsuke Sogame
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk