shared_ptr/intrusive_ptr conflict
Hi, Following snippet fails to compile with gcc 4: ---------------- #include <boost/shared_ptr.hpp> #include <boost/intrusive_ptr.hpp> boost::shared_ptr<void> sharedPtr; template <class T> boost::shared_ptr<T> get_concrete() { return boost::static_pointer_cast<T,void>(sharedPtr); } int main() { boost::shared_ptr<int> p = get_concrete<int>(); } ---------------- due to the presence of intrusive_ptr.hpp. it seems like SFINAE should have kicked in. Any help with how to work this around? Do we need to fix above header? Gennadiy.
Am Wednesday 20 January 2010 19:59:11 schrieb Gennadiy Rozental:
template <class T> boost::shared_ptr<T> get_concrete() { return boost::static_pointer_cast<T,void>(sharedPtr); }
int main() { boost::shared_ptr<int> p = get_concrete<int>(); } ----------------
due to the presence of intrusive_ptr.hpp. it seems like SFINAE should have kicked in.
Any help with how to work this around? Do we need to fix above header?
I'm not sure why that is, static_pointer_cast is an overload without any SFINAE involvement that should still match to shared_ptr, but the workaround is simple: remove the unnecessary "void" template argument in get_concrete.
Stefan Strasser <strasser <at> uni-bremen.de> writes:
I'm not sure why that is, static_pointer_cast is an overload without any SFINAE involvement
I think it trying to instantiate all the overloads for the static_pointer_cast before deciding which one to use. And it fails with overloads for intrusive_ptr<void>, which is in my opinion is the case of SFINAE, isn't it?
that should still match to shared_ptr, but the workaround is simple: remove the unnecessary "void" template argument in get_concrete.
It does work. Thanks. Gennadiy
participants (2)
-
Gennadiy Rozental -
Stefan Strasser