[range] iterator_range fixes for gcc-2.95.x
Hi Thorsten, I see that gcc-2.95.x is not one of the supported platforms for range, and I assume that there is a good reason for this. However, I have a couple small changes to iterator_range which will make it work well enough on gcc-2.95 for the purposes of the iostreams library, and I'd like permission to commit. I also added some fixes for Intel. Here are the tests I've conducted: VC7.1: passes all tests but mfc Intel 8.0 (windows): passes all tests but mfc Borland 5.6.4: passes all tests but mfc and array (failure in Boost.Test) GCC 3.4.1: passes all tests but mfc GCC 3.2 (MinGW): passes all tests but mfc VC7.0: passes no tests, but same was true prior to the changes, on my installation (although the regression reports show three tests passing) Also, I've updated mfc/cstring and carray to use the new metafunction names, and made some fixes so that they compile on windows, but have not tried linking them. Jonathan
Hi Jonathan, On Tue, Feb 08, 2005 at 01:39:26PM -0700, Jonathan Turkanis wrote:
VC7.0: passes no tests, but same was true prior to the changes, on my installation (although the regression reports show three tests passing)
Let me just comment this issue. I have created a workable core for the vc7.0 It was used by the string_algo internaly until I have switched to the Boost.Range. I was discussing the issue with Thorsten, and as the result I'm looking for a way how to integrate my workaround code into the current version of Boost.Range. However, I have no access to vc7.0 compiler so I will take a while until I will finish it. If you have access to it and some time to spare, it could help a lot. Regards, Pavol.
Hi Jonathan,
On Tue, Feb 08, 2005 at 01:39:26PM -0700, Jonathan Turkanis wrote:
VC7.0: passes no tests, but same was true prior to the changes, on my installation (although the regression reports show three tests passing)
Let me just comment this issue. I have created a workable core for the vc7.0 It was used by the string_algo internaly until I have switched to
Pavol Droba wrote: the
Boost.Range.
I was discussing the issue with Thorsten, and as the result I'm looking for a way how to integrate my workaround code into the current version of Boost.Range.
However, I have no access to vc7.0 compiler so I will take a while until I will finish it. If you have access to it and some time to spare, it could help a lot.
Well, I don't have too much time to spare, but perhaps it won't take long. Should I start with algorithm/string/collection_traits.hpp and algorithm/string/iterator_range.hpp, rev 1.6, or do you have a more recent version?
Pavol.
Jonathan
On Tue, Feb 08, 2005 at 03:08:29PM -0700, Jonathan Turkanis wrote:
Hi Jonathan,
On Tue, Feb 08, 2005 at 01:39:26PM -0700, Jonathan Turkanis wrote:
VC7.0: passes no tests, but same was true prior to the changes, on my installation (although the regression reports show three tests passing)
Let me just comment this issue. I have created a workable core for the vc7.0 It was used by the string_algo internaly until I have switched to
Pavol Droba wrote: the
Boost.Range.
I was discussing the issue with Thorsten, and as the result I'm looking for a way how to integrate my workaround code into the current version of Boost.Range.
However, I have no access to vc7.0 compiler so I will take a while until I will finish it. If you have access to it and some time to spare, it could help a lot.
Well, I don't have too much time to spare, but perhaps it won't take long. Should I start with algorithm/string/collection_traits.hpp and algorithm/string/iterator_range.hpp, rev 1.6, or do you have a more recent version?
According to my observation, it seems, that current workaround code, located in range/detail/common.h is not working properly. This code is supposed to qualify the kind of range being used. The qualification seems to be failing. I have developed different scheme, and it is located in the collection_traits* files. Unfortunately, this files are no longer compatible. collection_traits* was designed for the older version of range library. So, the code has to be ported to make it usable. To make thing easier, it should be enough if the array recognition code is ported, since the rest of the stuff is generaly the same. However, it is still possible, that the current code is generaly okey, just it needs some final touch. Maybe this is the best way you can go. If you'll be able to localize the problematic spot, we can either fix it, or rework it. Regards, Pavol
"Jonathan Turkanis" <technews@kangaroologic.com> wrote in message news:cub89o$7uu$1@sea.gmane.org... | Hi Thorsten, | | I see that gcc-2.95.x is not one of the supported platforms for range, and I | assume that there is a good reason for this. However, I have a couple small | changes to iterator_range which will make it work well enough on gcc-2.95 for | the purposes of the iostreams library, and I'd like permission to commit. please do, but ask pavol if its interferes with his changes. br -Thorsten
participants (3)
-
Jonathan Turkanis -
Pavol Droba -
Thorsten Ottosen