Detecting smart pointers: is_deferencable, a solution?
Following requests for a way to detect smart pointers, I've attached below a small trait that detects whether a type can be dereferenced or not. At present I can't see any downside to this? Anyone spot any potential flaws? John.
Doesn't work for void operator*(B&), but can we call such class dereferencable? :)
John Maddock wrote:
Dmitry Ivankov wrote:
Doesn't work for void operator*(B&), but can we call such class dereferencable? :)
No, I think there will always be some corner cases like that where it blows up, but does anyone really write such an operator in practice?
It's quite possible to handle the case where *x is void. See for example boost/detail/is_incrementable.hpp. A couple of years ago, I tried to generalize this into something reusable and more powerful. The result of that is available in the sandbox; boost/result_check.hpp. The intended usage was something like: BOOST_RESULT_CHECK(1, operator*, dereference, *_1) ^ ^ ^ ^ arity ----' | | | function -' | | metafunction name -' | operation -' template <class T> struct is_dereferencable : check_dereference<T> {}; template <class T> struct is_dereference_void : check_dereference<T, boost::is_void<mpl::_> > {}; template <class T, class U> struct is_dereference_convertible_to : check_dereference<T, boost::is_convertible<mpl::_, U> > {}; -- Daniel Wallin Boost Consulting www.boost-consulting.com
Daniel Wallin wrote:
John Maddock wrote:
Dmitry Ivankov wrote:
Doesn't work for void operator*(B&), but can we call such class dereferencable? :)
No, I think there will always be some corner cases like that where it blows up, but does anyone really write such an operator in practice?
It's quite possible to handle the case where *x is void. See for example boost/detail/is_incrementable.hpp. A couple of years ago, I tried to generalize this into something reusable and more powerful. The result of that is available in the sandbox; boost/result_check.hpp. The intended usage was something like:
BOOST_RESULT_CHECK(1, operator*, dereference, *_1) ^ ^ ^ ^ arity ----' | | | function -' | | metafunction name -' | operation -'
template <class T> struct is_dereferencable : check_dereference<T> {};
template <class T> struct is_dereference_void : check_dereference<T, boost::is_void<mpl::_> > {};
template <class T, class U> struct is_dereference_convertible_to : check_dereference<T, boost::is_convertible<mpl::_, U> > {};
Very interesting, I've had a play with that, and it does indeed seem to be a superior solution. Thanks! John.
On 1/21/07, John Maddock <john@johnmaddock.co.uk> wrote:
Following requests for a way to detect smart pointers, I've attached below a small trait that detects whether a type can be dereferenced or not.
Should an optional count as a pointer? Or by detecting a smart pointer do people just mean that it models http://boost.org/libs/utility/OptionalPointee.html ?
At present I can't see any downside to this? Anyone spot any potential flaws?
me22 wrote:
On 1/21/07, John Maddock <john@johnmaddock.co.uk> wrote:
Following requests for a way to detect smart pointers, I've attached below a small trait that detects whether a type can be dereferenced or not.
Should an optional count as a pointer?
Well it does get detected as dereferencable. Whether it should is open to debate I guess, but it's certainly "pointer like". John.
participants (4)
-
Daniel Wallin -
Dmitry Ivankov -
John Maddock -
me22