Re: [boost] Boost.Test, lexical_cast and gcc-2.95.3
Anything that uses Boost.Test is currently failing with gcc-2.95.3, see for example: http://tinyurl.com/dkreq I'm not sure if this is a lexical_cast or test lib change that's broken
things?
Google tells us that GCC 2.95 does not provide char_traits<>::eof(), hence the problem. I can confirm the attached patch solves the issue. OK to commit? A better way to macro-detect the offending platform? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo 157c157,167 < stream.get() == std::char_traits<char_type>::eof(); ---
stream.get() == #if defined(__GNUC__) && (__GNUC__==2) && (__GNUC_MINOR__==95) && \ defined(BOOST_NO_STD_WSTRING) // GCC 2.95 lacks std::char_traits<>::eof(). // We use BOOST_NO_STD_WSTRING to filter out STLport configurations, // which do provide std::char_traits<>::eof().
EOF; #else std::char_traits<char_type>::eof(); #endif
On Mon, Jun 20, 2005 at 08:58:12AM +0200, Joaqu?n M? L?pez Mu?oz wrote:
Anything that uses Boost.Test is currently failing with gcc-2.95.3, see for example: http://tinyurl.com/dkreq I'm not sure if this is a lexical_cast or test lib change that's broken
things?
Google tells us that GCC 2.95 does not provide char_traits<>::eof(), hence the problem. I can confirm the attached patch solves the issue. OK to commit? A better way to macro-detect the offending platform?
I think the version check should be for any GCC < 3 I think checking BOOST_NO_STD_WSTRING is right, since that will always get set for libstdc++-v2 (so won't be set if using an early snapshot of libstdc++-v3 with GCC 2.9x) jon
Joaqu?n M L?pez Mu?oz Telef?nica, Investigaci?n y Desarrollo
157c157,167 < stream.get() == std::char_traits<char_type>::eof(); ---
stream.get() == #if defined(__GNUC__) && (__GNUC__==2) && (__GNUC_MINOR__==95) && \ defined(BOOST_NO_STD_WSTRING) // GCC 2.95 lacks std::char_traits<>::eof(). // We use BOOST_NO_STD_WSTRING to filter out STLport configurations, // which do provide std::char_traits<>::eof().
EOF; #else std::char_traits<char_type>::eof(); #endif
Jonathan Wakely ha escrito:
On Mon, Jun 20, 2005 at 08:58:12AM +0200, Joaqu?n M? L?pez Mu?oz wrote:
Anything that uses Boost.Test is currently failing with gcc-2.95.3, see for example: http://tinyurl.com/dkreq I'm not sure if this is a lexical_cast or test lib change that's broken
things?
Google tells us that GCC 2.95 does not provide char_traits<>::eof(), hence the problem. I can confirm the attached patch solves the issue. OK to commit? A better way to macro-detect the offending platform?
I think the version check should be for any GCC < 3
I think checking BOOST_NO_STD_WSTRING is right, since that will always get set for libstdc++-v2 (so won't be set if using an early snapshot of libstdc++-v3 with GCC 2.9x)
OK, I have just commited according to your suggestions. Thank you! Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Jonathan Wakely wrote:
On Mon, Jun 20, 2005 at 08:58:12AM +0200, Joaqu?n M? L?pez Mu?oz wrote: [...]
Google tells us that GCC 2.95 does not provide char_traits<>::eof(), hence the problem. I can confirm the attached patch solves the issue. OK to commit? A better way to macro-detect the offending platform?
I think the version check should be for any GCC < 3
The problem doesn't exist if stlport is used with gcc 2.95. So, checking for the compiler version seems wrong. Regards, m Send instant messages to your online friends http://au.messenger.yahoo.com
Martin Wille ha escrito:
Jonathan Wakely wrote:
On Mon, Jun 20, 2005 at 08:58:12AM +0200, Joaqu?n M? L?pez Mu?oz wrote: [...]
Google tells us that GCC 2.95 does not provide char_traits<>::eof(), hence the problem. I can confirm the attached patch solves the issue. OK to commit? A better way to macro-detect the offending platform?
I think the version check should be for any GCC < 3
The problem doesn't exist if stlport is used with gcc 2.95. So, checking for the compiler version seems wrong.
I don't agree here: For instance, in mingw-3_4_2, BOOST_NO_STD_WSTRING is defined, yet the workaround is not necessary: checking for the compiler version correctly handles this. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
On Mon, Jun 20, 2005 at 02:24:47PM +0200, Joaqu?n M? L?pez Mu?oz wrote:
Martin Wille ha escrito:
Jonathan Wakely wrote:
On Mon, Jun 20, 2005 at 08:58:12AM +0200, Joaqu?n M? L?pez Mu?oz wrote: [...]
Google tells us that GCC 2.95 does not provide char_traits<>::eof(), hence the problem. I can confirm the attached patch solves the issue. OK to commit? A better way to macro-detect the offending platform?
I think the version check should be for any GCC < 3
The problem doesn't exist if stlport is used with gcc 2.95. So, checking for the compiler version seems wrong.
I don't agree here: For instance, in mingw-3_4_2, BOOST_NO_STD_WSTRING is defined, yet the workaround is not necessary: checking for the compiler version correctly handles this.
For clarity, boost/config/stdlib/sgi.hpp includes the following: #if (defined(__GNUC__) && (__GNUC__ < 3)) # include <string> # if defined(__BASTRING__) # define BOOST_NO_LIMITS // Note: <boost/limits.hpp> will provide compile-time constants # undef BOOST_NO_LIMITS_COMPILE_TIME_CONSTANTS # define BOOST_NO_STD_WSTRING # endif #endif That will be triggered if GCC 2.x is used with the default stdlib (libstdc++-v2) but not if it is used with STLport or libstdc++-v3 (because __BASTRING__ is the include guard from libstdc++-v2's <string> header) A more precise check would be to duplicate that test in lexical_cast, but since it's been done once by the config headers, I think it is reasonable to use the result of that check (i.e. BOOST_NO_STD_WSTRING being defined) to infer that we're using libstdc++-v2. Alternatively, sgi.hpp could additionally define BOOST_GCC_LIBSTDCPP_V2 and that could be used by lexical_cast. jon
On Mon, Jun 20, 2005 at 01:50:08PM +0200, Martin Wille wrote:
Jonathan Wakely wrote:
On Mon, Jun 20, 2005 at 08:58:12AM +0200, Joaqu?n M? L?pez Mu?oz wrote: [...]
Google tells us that GCC 2.95 does not provide char_traits<>::eof(), hence the problem. I can confirm the attached patch solves the issue. OK to commit? A better way to macro-detect the offending platform?
I think the version check should be for any GCC < 3
The problem doesn't exist if stlport is used with gcc 2.95. So, checking for the compiler version seems wrong.
Checking _just_ the compiler version would be wrong, but checking for BOOST_NO_STD_WSTRING as well should mean it catches GCC 2.x with libstdc++-v2 but not GCC 2.x with STLport or libstdc++-v3 snapshots. I haven't tested it though. Does GCC 2.x with STLport support std::wstring (and therefore leave BOOST_NO_STD_WSTRING undefined) ? jon -- "The ability to quote is a serviceable substitute for wit." - W. Sommerset Maugham
Jonathan Wakely ha escrito:
On Mon, Jun 20, 2005 at 01:50:08PM +0200, Martin Wille wrote:
Jonathan Wakely wrote:
On Mon, Jun 20, 2005 at 08:58:12AM +0200, Joaqu?n M? L?pez Mu?oz wrote: [...]
Google tells us that GCC 2.95 does not provide char_traits<>::eof(), hence the problem. I can confirm the attached patch solves the issue. OK to commit? A better way to macro-detect the offending platform?
I think the version check should be for any GCC < 3
The problem doesn't exist if stlport is used with gcc 2.95. So, checking for the compiler version seems wrong.
Checking _just_ the compiler version would be wrong, but checking for BOOST_NO_STD_WSTRING as well should mean it catches GCC 2.x with libstdc++-v2 but not GCC 2.x with STLport or libstdc++-v3 snapshots.
I haven't tested it though. Does GCC 2.x with STLport support std::wstring (and therefore leave BOOST_NO_STD_WSTRING undefined) ?
Yes, see http://tinyurl.com/d5gc6. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Jonathan Wakely wrote:
On Mon, Jun 20, 2005 at 01:50:08PM +0200, Martin Wille wrote: [...]
Google tells us that GCC 2.95 does not provide char_traits<>::eof(), hence the problem. I can confirm the attached patch solves the issue. OK to commit? A better way to macro-detect the offending platform?
I think the version check should be for any GCC < 3
The problem doesn't exist if stlport is used with gcc 2.95. So, checking for the compiler version seems wrong.
Checking _just_ the compiler version would be wrong, but checking for BOOST_NO_STD_WSTRING as well should mean it catches GCC 2.x with libstdc++-v2 but not GCC 2.x with STLport or libstdc++-v3 snapshots.
Thanks for the clarification.
I haven't tested it though. Does GCC 2.x with STLport support std::wstring (and therefore leave BOOST_NO_STD_WSTRING undefined) ?
Yes, it supports wstring and it leaves BOOST_NO_STD_WSTRING undefined. Regards, m Send instant messages to your online friends http://au.messenger.yahoo.com
participants (3)
-
Joaquín Mª López Muñoz -
Jonathan Wakely -
Martin Wille