[boost] Re: [range] vc support update

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2005-05-10 12:57:20

Thorsten Ottosen wrote:
> "Jonathan Turkanis" <technews_at_[hidden]> wrote in message
> news:d5ot7b$5d9$1_at_sea.gmane.org...
>> [My email to Thorsten bounced, so I'm posting it here]
>
> ok, any idea why? [did you use nesotto_at_[hidden] or
> nesotto_at_[hidden]?] the former is the new one.

Hmmm ... it looks like I used tottosen_at_[hidden]; I guess this is old.

>> Thorsten,
>>
>> I finally got around to Boost.Range today. Sorry for the long delay.
>
> thankyou for doing it!

You're welcome.

>> There are two points which deserve mention:

>> 2. With VC6, the function template arguments to range_end<>::fun()
>> and range_size_<>::fun() were not deduced properly, leading to
>> compiler errors. Since explicitly specifying the arguments caused
>> internal errors, I used a trick from iostreams, and put the static
>> function fun() in a nested class template whose template argument
>> can be explicitly specified without problem; e.g.:

>>        template< typename C >
>>    inline BOOST_DEDUCED_TYPENAME range_result_iterator<C>::type
>>    end( C& c )
>>    {
>>        return range_detail::range_end<range_detail::range<C>::type>::
>>            inner<C>::fun( c );
>>    }
>
> Don't you need BOOST_NESTED_TEMPLATE before "inner"?

Not for VC6. Actually, I could get rid of BOOST_DEDUCED_TYPENAME too, for
readability.

>> This workaround is applied only for VC6. My question is: does this
>> interfere with the extension protocol? If so, I think I can fix it,
>> but only by adding another level of indirection.
>
> I don't think it interferes...extending the lib portably is really
> hard if the type is a class template.
>
>> If you approve, I'll commit these changes.
>
> please do.

Okay.

>> I haven't started working on Borland
>> or GCC 2.9x yet.
>
> You're gonna do those too. :-)

If I can ;-) The iostreams regression tests use iterator_range, which doesn't
work on 2.9x.

> -Thorsten

Jonathan