Thorsten Ottosen wrote:
"Jonathan Turkanis" <technews@kangaroologic.com> wrote in message news:d5ot7b$5d9$1@sea.gmane.org...
[My email to Thorsten bounced, so I'm posting it here]
ok, any idea why? [did you use nesotto@cs.aau.dk or nesotto@cs.auc.dk?] the former is the new one.
Hmmm ... it looks like I used tottosen@dezide.dk; 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