Complete vs incomplete (fwd decl'd) types

In client code including the header for MyDerived, I'm using a MyPtr<MyDerived>, but the static assert below was failing. It took me a little while to figure out that in myderived.h, the MyDerived::nested_type typedef is using a forward-declared MyNestedDerived type declared in my_nested_derived.h, that the client code was not including, which was the reason is_base_of was failing with the error below (Boost 1.41, VC9). Adding a #include <my_nested_derived.h> fixed it. boost\type_traits\is_base_and_derived.hpp(228) : error C2139: 'MyNestedDerived' : an undefined class is not allowed as an argument to compiler intrinsic type trait '__is_base_of' But is there a way to get a more obvious error message stating that MyNestedDerived is an incomplete type or something? In retrospect the message is not that bad, but I'm hoping there's a better way. Thanks, --DD PS: Of course there's a reason the nested type is in a separate header, and it's an idiom repeated often in our code base. template <class E> class MyPtr { public: ... typedef typename E::nested_type nested_type; explicit MyPtr(const shared_ptr<nested_type>& n) : ... { BOOST_STATIC_ASSERT((is_base_of<MyNestedBase, nested_type>::value)); } ... };

AMDG Dominique Devienne wrote:
In client code including the header for MyDerived, I'm using a MyPtr<MyDerived>, but the static assert below was failing. It took me a little while to figure out that in myderived.h, the MyDerived::nested_type typedef is using a forward-declared MyNestedDerived type declared in my_nested_derived.h, that the client code was not including, which was the reason is_base_of was failing with the error below (Boost 1.41, VC9). Adding a #include <my_nested_derived.h> fixed it.
boost\type_traits\is_base_and_derived.hpp(228) : error C2139: 'MyNestedDerived' : an undefined class is not allowed as an argument to compiler intrinsic type trait '__is_base_of'
But is there a way to get a more obvious error message stating that MyNestedDerived is an incomplete type or something? In retrospect the message is not that bad, but I'm hoping there's a better way.
It seems to me that it's the compiler's job to provide a good error message in this case. I don't see that there's very much we can do inside Boost to improve it. In Christ, Steven Watanabe
participants (2)
-
Dominique Devienne
-
Steven Watanabe