Re: [boost] [range] iterator_range::operator[] broken

Subject: Re: [boost] [range] iterator_range::operator[] broken
From: Neil Groves (neil_at_[hidden])
Date: 2010-04-14 04:49:44

>
>
>> I'm seeing massive breakages all over trunk and release, not all of
>> which are related to the changed return type of
>> iterator_range::operator[]. For instance, there seems to be some new
>> ambiguity in the "detail" symbol. See for instance:
>>
>>
>> http://beta.boost.org/development/tests/release/developer/output/RW_WinXP_VC-boost-bin-v2-libs-accumulators-test-covariance-test-msvc-8-0-debug-iterator_debugging-off-link-static-threading-multi.html
>>
>> I can't be certain at this point if RangeEx is responsible, but it's
>> where I would start looking. Could you have a look and report back?
>>
>
>
This has relationship to changes in Boost.Range. The error:

..\boost/smart_ptr/detail/sp_counted_impl.hpp(81) : error C2872:
'detail' : ambiguous symbol
        could be 'boost::detail'
        or 'boost::numeric::operators::detail'
        ..\boost/smart_ptr/detail/shared_count.hpp(87) : see reference
to class template instantiation 'boost::detail::sp_counted_impl_p<X>'
being compiled
        with

Is because of a potential ambiguity between ::boost::detail and the
::boost::numeric::operators::detail. This is can be fixed by prefixing
the changing

virtual void * get_deleter( detail::sp_typeinfo const& )

to

virtual void * get_deleter( boost::detail::sp_typeinfo const& )

The probability of Boost.Range changes causing other ambiguity with
the detail namespace is very low since I chose to use the range_detail
namespace to avoid exactly this type of issue. However I accept that I
have changed header dependencies and this can trigger this type of
event. For this specific example the solution seems very simple. Would
you like be to apply the change to sp_counted_impl.hpp?

Regards,

Neil Groves