[boost] Re: [range] vc support update

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2005-05-10 12:31:48

"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.

| 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