On Wed, May 25, 2011 at 5:22 AM, Arno Schödl <aschoedl@think-cell.com>wrote:
--- C:/Program Files (x86)/Microsoft Visual Studio
9.0/VC/boost_1_46_1/boost/iterator/iterator_facade.hpp Wed May 25 11:42:14 2011
+++ C:/Program Files (x86)/Microsoft Visual Studio 9.0/VC/boost_1_46_1/boost/iterator/iterator_facade - Copy.hpp Wed May 25 11:41:49 2011 @@ -819,8 +819,8 @@ is_interoperable< Derived1, Derived2>::value \ )); \ return_prefix iterator_core_access::base_op( \ - *static_cast<Derived1 const*>(&lhs) \ - , *static_cast<Derived2 const*>(&rhs) \ + static_cast<Derived1 const&>(lhs) \ + , static_cast<Derived2 const&>(rhs) \ , BOOST_ITERATOR_CONVERTIBLE(Derived2,Derived1) \ ); \ }
An alternative could also have been to use boost::addressof
I was aware of that, but creating the dependency on addressof seems unnecessary if a simple reference cast does the job. Is there any particular reason why the cast is implemented through pointers?
Searching through boost for *static_cast, there are a few more places where a static_cast< [const] & > would do but the route through pointers has been taken. Any reason not to replace them wholesale to avoid problems with overloaded operator& and in general to make the code more concise?
I believe casting through pointers is more restrictive and predictable than casting through references (e.g., T& could be even implicitly convertible to U& without T* convertible to U*; even the case of converting base_type& to derived_type& could be using some converting constructor in derived_type), so I don't think this would be a wise change indiscriminately. It looks to me like in this iterator_facade case, though, a reference cast is probably fine... [...snip instances of "*static_cast<" in boost...] - Jeff