Re: [boost] generally replace *static_cast< T [const]* >(&x) -> static_cast< T [const]& >(x)?

Subject: Re: [boost] generally replace *static_cast< T [const]* >(&x) -> static_cast< T [const]& >(x)?
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2011-05-25 15:28:25

On Wed, May 25, 2011 at 5:22 AM, Arno Schödl <aschoedl_at_[hidden]>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