|
Boost : |
From: Douglas Gregor (gregod_at_[hidden])
Date: 2002-11-12 11:38:53
On Tuesday 12 November 2002 04:26 am, Aleksey Gurtovoy wrote:
> Well, since that particular reason of type deduction failure (attempting to
> call a member function on the object which type does not contain the
> specified member) is not explicitly listed under 14.8.2 para 2, yes, in one
> or another form. I haven't figured out yet what would be the best way
> (politically and technically) to get that part of the language into the
> state we would like it to have ;).
Once we've solved the "technically", I think the politically best way to
handle this would be to submit a very detailed defect report. The problem is
easy to point out, and it is easy to give a case where the standard is
ambiguous. However, we must give the committee the "big picture" regarding
their decision: resolving the defect "our way" will make C++ a vastly more
powerful and more safe language, because we will have the power to do
concept-checking without spewing mountains of errors when we find a failure.
And someone better be at the meeting when the committee discusses this :)
[snip code]
> template< typename Functor, typename R, typename T1 >
> yes_tag is_callable_helper(
> sink< sizeof(static_cast<R>(
> get<Functor>().Functor::operator()( get<T1>() ) // here
> ))>
> );
[snip more code]
> The marked line falls directly under one of the 14.8.2 para 2's items:
>
> "-- Attempting to use a type in the qualifier portion of a qualified name
> that names a type when that
> type does not contain the specified member [...]"
Right, but if there is an operator() but no operator() that takes a single
parameter of a type convertible from T1, or if the return type can't be
static_cast to R, we're back to a case that isn't listed in 14.8.2 paragraph
2.
Doug
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk