[iostreams] fix for vc-6_5
Recent changes to boost/iostreams/positioning.hpp cause VC 6.5 to fail as for instance in http://tinyurl.com/jkdhx . The simple problem is that Dinkum lib for this compiler does not define fpos_t in namespace std, only as a global type. The attached patch just reverts to global ::fpos_t under the aforementioned circumstances. Is there any objection to my commiting to trunk and RC_1_34_0? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo 16a17
#include <boost/config.hpp> 17a19 #include <boost/detail/workaround.hpp> 48a51,53 #if BOOST_WORKAROUND(BOOST_MSVC, < 1300) && defined(BOOST_DINKUMWARE_STDLIB) inline stream_offset fpos_t_to_offset(::fpos_t pos) #else 49a55 #endif
On Wed, 19 Jul 2006 08:31:16 +0200, Joaquín Mª López Muñoz <joaquin@tid.es> wrote:
Dinkum lib for this compiler does not define fpos_t in namespace
std, only as a global type. The attached patch just reverts to global ::fpos_t under the aforementioned circumstances.
Is there any objection to my commiting to trunk and RC_1_34_0?
The way boost usually handles this is: #ifdef BOOST_NO_STDC_NAMESPACE namespace std { using ::fpost_t; } #endif in one of the "low level" source files (iostreams/config.hpp or similar). All the "above" code remains untouched. -- [ Gennaro Prota, C++ developer for hire ] [ resume: available on request ]
Gennaro Prota ha escrito:
On Wed, 19 Jul 2006 08:31:16 +0200, Joaquín Mª López Muñoz <joaquin@tid.es> wrote:
Dinkum lib for this compiler does not define fpos_t in namespace
std, only as a global type. The attached patch just reverts to global ::fpos_t under the aforementioned circumstances.
Is there any objection to my commiting to trunk and RC_1_34_0?
The way boost usually handles this is:
#ifdef BOOST_NO_STDC_NAMESPACE namespace std { using ::fpost_t; } #endif
in one of the "low level" source files (iostreams/config.hpp or similar). All the "above" code remains untouched.
Hi Gennaro, you're absolutely right, and the method you propose looks much neater. I've inspected iostreams code base and the lib does not have a centralized header for this kind of hacks, yet there are several other BOOST_NO_STDC_NAMESPACE scattered on the places of usage, so I decided to keep that style and put the using in positioning.hpp itself. Does this look OK to you? Any other objection to my commiting this new diff? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo 16a17
#include <boost/config.hpp> 23a25,28
#ifdef BOOST_NO_STDC_NAMESPACE namespace std { using ::fpos_t; } #endif
On Wed, 19 Jul 2006 19:54:32 +0200, Joaquín Mª López Muñoz <joaquin@tid.es> wrote:
I've inspected iostreams code base and the lib does not have a centralized header for this kind of hacks, yet there are several other BOOST_NO_STDC_NAMESPACE scattered on the places of usage, so I decided to keep that style and put the using in positioning.hpp itself.
Does this look OK to you? Any other objection to my commiting this new diff?
Hi Joaquín, thanks for analyzing the issue. Yes, that looks ok to me (off-hand I can't see where <cstdio> gets included, but I hope it is!). I'd say just go with it. :-) -- [ Gennaro Prota, C++ developer for hire ] [ resume: available on request ]
Gennaro Prota ha escrito:
On Wed, 19 Jul 2006 19:54:32 +0200, Joaquín Mª López Muñoz <joaquin@tid.es> wrote:
I've inspected iostreams code base and the lib does not have a centralized header for this kind of hacks, yet there are several other BOOST_NO_STDC_NAMESPACE scattered on the places of usage, so I decided to keep that style and put the using in positioning.hpp itself.
Does this look OK to you? Any other objection to my commiting this new diff?
Hi Joaquín,
thanks for analyzing the issue.
Unless we all begin chasing red cells down we will never get 1.34 out of the door.
Yes, that looks ok to me (off-hand I can't see where <cstdio> gets included, but I hope it is!).
I thought the same, but regression tests show that the stuff is indeed included, so I decided not to touch the code any more than strictly necessary.
I'd say just go with it. :-)
Done. Best regards, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
-- [ Gennaro Prota, C++ developer for hire ] [ resume: available on request ]
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Thu, 20 Jul 2006 08:03:08 +0200, Joaquín Mª López Muñoz <joaquin@tid.es> wrote:
Unless we all begin chasing red cells down we will never get 1.34 out of the door.
Yes, we have admittedly some problems with that. I asked myself why and I think it is in part due to the number of interesting proposals which are regularly submitted, in part to the high commitment of many boost members to the WG21 committee, which has set a pretty aggressive schedule both for TR2 and C++0x. Another facet of the problem is coupling between libraries. I think once 1.34.0 is out it will be worth to devote some thoughts to this.
Yes, that looks ok to me (off-hand I can't see where <cstdio> gets included, but I hope it is!).
I thought the same, but regression tests show that the stuff is indeed included, so I decided not to touch the code any more than strictly necessary.
Yeah, let's hope we are not relying on undefined behavior :-)
I'd say just go with it. :-)
Done.
Thanks. Just one thing: I meant to wittily say "go for it". I'm not sure whether the meanings are different, but since when a native speaker made me notice that "to go along" and "to get along" are totally different things I'm a bit more cautious with verb + preposition combinations :-) -- [ Gennaro Prota, C++ developer for hire ] [ resume: available on request ]
Gennaro Prota ha escrito:
On Thu, 20 Jul 2006 08:03:08 +0200, Joaquín Mª López Muñoz <joaquin@tid.es> wrote:
Unless we all begin chasing red cells down we will never get 1.34 out of the door.
Yes, we have admittedly some problems with that. I asked myself why and I think it is in part due to the number of interesting proposals which are regularly submitted, in part to the high commitment of many boost members to the WG21 committee, which has set a pretty aggressive schedule both for TR2 and C++0x.
I'm not so sure about those reasons you propose. Having a cursory inspection of the regression tests landscape, I'd say the main sources of red and yellow cells are, roughly ordered in decreasing importance measured as no of failures: 1. More or less exotic compilers for which nobody cares to try to fix things or, at least, mark whole libs as unusable on them. 2. Toolsets with some kind of configuration problem. 3. Abandoned libs. 4. Libs which are strictly not abandoned (the author hangs around the lists) but need some more attention: even if the codebase does not change, problems in 3rd party libs can result in regressions here. Probably the most worrysome areas are #3 and #4. I don't think the reasons you brought up can be used to explain these, at least not #3. In the short term, the only thing we can probably do is devote some spare time to greenify regressions, which is what I try to do when I can spend an hour or two on this: many of the problems are relatively simple to fix if you have access to the problematic compiler. In the longer term, declaring some libs as abandoned and eventually getting someone to maintain them would be IMHO the best course of action.
Another facet of the problem is coupling between libraries. I think once 1.34.0 is out it will be worth to devote some thoughts to this.
Beman Dawes proposed a very attractive maintenance and release scheme designed to avoid this kind of situations. http://lists.boost.org/Archives/boost/2006/05/104654.php Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
On Thu, 20 Jul 2006 19:54:47 +0200, Joaquín Mª López Muñoz <joaquin@tid.es> wrote:
I'm not so sure about those reasons you propose. Having a cursory inspection of the regression tests landscape, I'd say the main sources of red and yellow cells are, roughly ordered in decreasing importance measured as no of failures:
1. More or less exotic compilers for which nobody cares to try to fix things or, at least, mark whole libs as unusable on them. 2. Toolsets with some kind of configuration problem. 3. Abandoned libs. 4. Libs which are strictly not abandoned (the author hangs around the lists) but need some more attention: even if the codebase does not change, problems in 3rd party libs can result in regressions here.
You may be right. It would probably help to be explicit and tell what libraries belong to what category. I don't think there's any reason for authors/maintainers to be offended. We are all here for the same purpose, and this can be a good way to improve our (way to) work.
[...]
Beman Dawes proposed a very attractive maintenance and release scheme designed to avoid this kind of situations.
I could only have a quick look, so I'll not comment on it yet. As to our regression reports I have noticed more "oversights" compared to earlier releases, e.g. forgetting to build libraries (a while ago almost all STLport 5 tests were failing because the iostream part of the library hadn't been built) and introduction of new compilers for which the library author was unprepared (as Dave has pointed out too, in French :-)). I also seize the occasion to say that some tests don't have to be "fixed" at all costs. I've just added a note about an old failure concerning dynamic_bitset references in conjunction with STLport 4.5.3: I could have probably found a workaround for it (though admittedly that wouldn't have been an easy task) but I didn't even try, as the error depend on a _serious_ flaw of STLport which can (and will) show up independently from dynamic_bitset. This is a typical case where an annotated failure is much more informative than a green-for-green's-sake cell. -- [ Gennaro Prota, C++ developer for hire ]
participants (2)
-
Gennaro Prota -
Joaquín Mª López Muñoz