On Sep 6, 2006, at 12:19 AM, David Abrahams wrote:
But that's probably not what you meant for it to do. In this case it looks like you have a kind of circular dependency problem. You can actually learn a lot by reading the error messages. Reversing your instantiation backtrace, I get:
test.cpp:36: instantiated from here
I assume that's the 2nd line of main()
test.cpp:36: instantiated from `boost::enable_if<boost::is_convertible<Foo, Foo>, void>'
It's trying to decide if the first ctor is a match
test.cpp:36: instantiated from `boost::is_convertible<Foo, Foo>'
Yes, everything up to this point was straightforward. The compiler is trying to choose between the constructors by instantiating the various enable_if templates. Unfortunately, I'm not as familiar with the internals of enable_if<> as many of you, and the *next* part was a bit confusing...
To do that it needs to decide the value nested in is_convertible<Foo,Foo>.
test.cpp:36: instantiated from `boost::detail::is_convertible_impl_dispatch<Foo, Foo>' /boost/boost/type_traits/is_convertible.hpp:228: instantiated from `boost::detail::is_convertible_impl<Foo, Foo>' /boost/boost/type_traits/is_convertible.hpp:128: instantiated from `boost::detail::is_convertible_basic_impl<Foo&, Foo>'
Inside implementation details of is_convertible:
/boost/boost/type_traits/is_convertible.hpp: In instantiation of `boost::disable_if<boost::is_convertible<Foo, Foo>, void>':
To determine convertibility it has to check out the ctors and see if there's one that implicitly converts Foo->Foo
...but it can't do that if the constructors that would perform the conversion are themselves enabled/disabled with enable_if?
/boost/boost/type_traits/is_convertible.hpp:128: error: `value' is not a member of type `boost::is_convertible<Foo, Foo>'
In evaluating the applicability of the first ctor, it needs to know the value nested in is_convertible<Foo,Foo>. We've been here before!
Right. So again, it seems as though it isn't possible to do what I'm trying to do. The enable_if<> template requires the use of the class' copy constructor. Even if a default copy constructor is provided, the compiler still wants to obtain the nested value type in is_convertible<>, and it can't do that, because it needs to decide between the three copy-constructor-like functions in the class, two of which depend on enable_if<> to determine their signatures. Is that the correct way to interpret this situation? In retrospect, this was probably too trivial an example to give you -- I realize that it's silly to want to use enable_if<> to do what the compiler can do for itself. There's a far more complex situation behind the question, but I'm having trouble distilling it down to a question of reasonable length.... -Tim