[range] vc support update
[My email to Thorsten bounced, so I'm posting it here] Thorsten, I finally got around to Boost.Range today. Sorry for the long delay. I've been able to get all the regression tests to pass on VC6, and all the tests to compile on VC7.0. I can't run the tests on the latter platform because of errors in Boost.Test. There are two points which deserve mention: 1. Array support only works for arrays of fundamental types. This should be mentioned in the docs, since it's not apparent from the regression test results. 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<> struct range_end<std_container_> { template< typename C > struct inner { static BOOST_RANGE_DEDUCED_TYPENAME range_result_iterator<C>::type fun( C& c ) { return c.end(); }; }; }; .... 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 ); } 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. If you approve, I'll commit these changes. I haven't started working on Borland or GCC 2.9x yet. Jonathan P.S. I ended up not using the collection_traits headers -- the new dispatch mechanism made that unnecessary.
Jonathan Turkanis wrote:
I've been able to get all the regression tests to pass on VC6, and all the tests to compile on VC7.0. I can't run the tests on the
I forgot to mention that the tests compile on VC7.0 only with language extensions enabled (which is the default). Jonathan
"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. | Thorsten, | | I finally got around to Boost.Range today. Sorry for the long delay. thankyou for doing it! | I've been able to get all the regression tests to pass on VC6, and all the tests | to compile on VC7.0. I can't run the tests on the latter platform because of | errors in Boost.Test. | | There are two points which deserve mention: | | 1. Array support only works for arrays of fundamental types. This should be | mentioned in the docs, since it's not apparent from the regression test results. ok, I'll mention that | 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<> | struct range_end<std_container_> | { | template< typename C > | struct inner { | static BOOST_RANGE_DEDUCED_TYPENAME | range_result_iterator<C>::type | fun( C& c ) | { | return c.end(); | }; | }; | }; | | .... | | 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"? | 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. | I haven't started working on Borland | or GCC 2.9x yet. You're gonna do those too. :-) -Thorsten
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
"Jonathan Turkanis" <technews@kangaroologic.com> wrote in message news:d5qsau$92v$1@sea.gmane.org... | 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. you could use thorsten.ottosen@dezide.dk too -Thorsten
participants (2)
-
Jonathan Turkanis -
Thorsten Ottosen