On 7/26/2011 11:20 AM, Victor Bazarov wrote:
On 7/26/2011 9:50 AM, Victor Bazarov wrote:
On 7/22/2011 5:14 PM, Noah Roberts wrote:
Trying to come up with a method to find out if a class contains a name
within it that is callable with certain variables, whether it's a
templated function or not.
Here's my attempt:
template < typename T > T&& declval(); // MSVC doesn't have.
Name was confusing to me so I changed it to 'xval' in my attempts.
The name is standard. MSVC simply doesn't implement it.
I've dug around a bit, and so far this is doesn't work as expected:
-------------------------------------
template < bool v > struct bool_ { enum { yesno = v }; };
typedef bool_<false> false_;
typedef bool_<true> true_;
template < typename T, typename U = void >
struct has_nested_type : false_
{
};
template < typename T >
struct has_nested_type<T, typename T::nested > : true_
{
};
struct test
{
typedef int nested;
};
struct noftest
{
};
int main()
{
static_assert(has_nested_type<test>::yesno, "test: BAD");
static_assert(has_nested_type<noftest>::yesno, "noftest: BAD");
}
-------------------------------------
which leads me to believe that either VC++ is not up to snuff yet on
instantiating the templates the way we think they ought to be
instantiated (so I'd like somebody to try that code with another C++0x
compliant compiler), or there is something we're missing with the way
the partial specialisation is supposed to be chosen over the generic
one. BTW, I tried it with Comeau online, and it also failed on both
assertions, which doesn't prove it's right, just makes me feel that I
need to dig more thoroughly around partial specialisations and their
instantiation.
I believe this fails because the type of the default parameter doesn't
match the type you supply in the specialization.
The line, has_nested_type<test> results in the compiler attempting to
instantiate has_nested_type<test,void>. The specialization results in
has_nested_type<test,int>. This doesn't match so it uses the
non-specialized case.
My problem seems to be specifically the fact that the decltype
expression in that location seems to confuse the compiler. The program
fails to compile whether or not the specialization is ever used.
Interestingly, I am able to use the exact same expression in a function
overload matcher:
template < typename T >
struct has_callable_f
{
typedef char (&no) [1];
typedef char (&yes) [2];
template < typename S >
static yes check(decltype(declval<S>().f(declval<int>())) *);
template < typename S >
static no check(...);
enum { value = sizeof(check<T>(nullptr)) == sizeof(yes) };
};
implements 'decltype' sensitively to the context... Oh well, maybe