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...]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk