Hi, I'm having some minor problems with Boost.Test. Using g++3.2, MinGW, I get: In file included from ../../../boost/test/included/unit_test_framework.hpp:20, from ../../../libs/spirit/test/actor/unit_test.cpp:9: ../../../libs/test/src/test_tools.cpp: In function `bool boost::test_tools::tt_detail::equal_and_continue_impl(const wchar_t*, const wchar_t*, boost::wrap_stringstream&, boost::unit_test::basic_cstring<const char>, unsigned int, boost::unit_test::log_level)': ../../../libs/test/src/test_tools.cpp:188: `wcscmp' undeclared in namespace ` std' unit_test.cpp is just: #include <boost/test/included/unit_test_framework.hpp> Any hints? Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Joel de Guzman wrote:
Hi,
I'm having some minor problems with Boost.Test. Using g++3.2, MinGW, I get:
In file included from ../../../boost/test/included/unit_test_framework.hpp:20, from ../../../libs/spirit/test/actor/unit_test.cpp:9: ../../../libs/test/src/test_tools.cpp: In function `bool boost::test_tools::tt_detail::equal_and_continue_impl(const wchar_t*, const wchar_t*, boost::wrap_stringstream&, boost::unit_test::basic_cstring<const char>, unsigned int, boost::unit_test::log_level)': ../../../libs/test/src/test_tools.cpp:188: `wcscmp' undeclared in namespace ` std'
unit_test.cpp is just: #include <boost/test/included/unit_test_framework.hpp>
IMO, there's nothing wrong with using namespace std; in local scope. Here's a fix: bool equal_and_continue_impl( wchar_t const* left, wchar_t const* right, wrap_stringstream& message, const_string file_name, std::size_t line_num, unit_test::log_level loglevel ) { using namespace std; bool predicate = (left && right) ? wcscmp( left, right ) == 0 : (left == right); ... } Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Joel de Guzman wrote: g++3.2 on MinGW has some trouble compiling boost/thread/detail/lock.hpp: ../../../boost/thread/detail/lock.hpp:30: semicolon missing after enum declaration Easy fix: enum lock_state { unlocked=0, locked=1 }; and enum blocking_mode { non_blocking=0, blocking=1 }; It's been a while since I've seen the old constructs such as: typedef enum { unlocked=0, locked=1 } lock_state; Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Joel de Guzman wrote:
Joel de Guzman wrote:
g++3.2 on MinGW has some trouble compiling boost/thread/detail/lock.hpp:
../../../boost/thread/detail/lock.hpp:30: semicolon missing after enum declaration
[...] The same problem is found in thread/read_write_mutex.hpp:37: and thread/detail/read_write_lock.hpp. *** There are also no newlines at the end of these files. *** Fixing all those above, Spirit compiles now with only one test failing. The failure is again because of boost.threads (again on MinGW, g++3.2) : read_write_mutex.cpp: In member function `void boost::detail::thread::read_write_mutex_impl<Mutex>::do_read_lock()': read_write_mutex.cpp:87: parse error before `(' token read_write_mutex.cpp: In member function `bool boost::detail::thread::read_write_mutex_impl<Mutex>::do_try_read_lock()': read_write_mutex.cpp:161: parse error before `(' token read_write_mutex.cpp: In member function `void boost::detail::thread::read_write_mutex_impl<Mutex>::do_read_lock() [with Mutex = boost::mutex]': read_write_mutex.cpp:621: instantiated from here read_write_mutex.cpp:98: `l' undeclared (first use this function) read_write_mutex.cpp:98: (Each undeclared identifier is reported only once for each function it appears in.) Any hints? Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Joel de Guzman wrote:
Joel de Guzman wrote:
Joel de Guzman wrote:
g++3.2 on MinGW has some trouble compiling boost/thread/detail/lock.hpp:
../../../boost/thread/detail/lock.hpp:30: semicolon missing after enum declaration
[...]
The same problem is found in thread/read_write_mutex.hpp:37: and thread/detail/read_write_lock.hpp.
Fixed.
*** There are also no newlines at the end of these files. ***
Fixed.
Fixing all those above, Spirit compiles now with only one test failing. The failure is again because of boost.threads (again on MinGW, g++3.2) :
read_write_mutex.cpp: In member function `void boost::detail::thread::read_write_mutex_impl<Mutex>::do_read_lock()': read_write_mutex.cpp:87: parse error before `(' token
read_write_mutex.cpp: In member function `bool
boost::detail::thread::read_write_mutex_impl<Mutex>::do_try_read_lock()': read_write_mutex.cpp:161: parse error before `(' token
read_write_mutex.cpp: In member function `void boost::detail::thread::read_write_mutex_impl<Mutex>::do_read_lock() [with Mutex = boost::mutex]':
read_write_mutex.cpp:621: instantiated from here
read_write_mutex.cpp:98: `l' undeclared (first use this function)
read_write_mutex.cpp:98: (Each undeclared identifier is reported only once for each function it appears in.)
Any hints?
No ideas at the moment. Mike
Michael Glassford wrote: [...]
Fixed.
*** There are also no newlines at the end of these files. ***
Fixed.
Fixing all those above, Spirit compiles now with only one test failing. The failure is again because of boost.threads (again on MinGW, g++3.2) :
[...]
No ideas at the moment.
I certainly hope that Boost.Threads finally settle down in a stable form. The MetaComm results show that it is in such a poor state. http://tinyurl.com/4s58j indicates that not a single test passes. A lot of libraries (including Spirit) rely on this library and time is running out. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Joel de Guzman wrote:
Michael Glassford wrote:
[...]
Fixed.
*** There are also no newlines at the end of these files. ***
Fixed.
Fixing all those above, Spirit compiles now with only one test failing. The failure is again because of boost.threads (again on MinGW, g++3.2) :
[...]
No ideas at the moment.
I certainly hope that Boost.Threads finally settle down in a stable form. The MetaComm results show that it is in such a poor state. http://tinyurl.com/4s58j indicates that not a single test passes. A lot of libraries (including Spirit) rely on this library and time is running out.
Yes, I just noticed this yesterday and was rather surprised: I had expected at least MSVC++ 6 and 7.1 to work, since I tested both of those. It's not in as bad shape as it looks, though, since almost all of the errors are the same: Cannot open include file: 'boost/thread/detail/config.hpp': No such file or directory This file is in CVS, and has been included in some files for quite a long time; the change I made was to include it in all files. Apparently I'm missing something, but I don't understand why the file isn't being found. Mike
On Wed, Jul 14, 2004 at 11:47:57AM -0400, Michael Glassford wrote:
I certainly hope that Boost.Threads finally settle down in a stable form. The MetaComm results show that it is in such a poor state. http://tinyurl.com/4s58j indicates that not a single test passes. A lot of libraries (including Spirit) rely on this library and time is running out.
Yes, I just noticed this yesterday and was rather surprised: I had expected at least MSVC++ 6 and 7.1 to work, since I tested both of those. It's not in as bad shape as it looks, though, since almost all of the errors are the same:
Cannot open include file: 'boost/thread/detail/config.hpp': No such file or directory
This file is in CVS, and has been included in some files for quite a long time; the change I made was to include it in all files. Apparently I'm missing something, but I don't understand why the file isn't being found.
Is it possible it's the stray DOS newline on line 12 of libs/thread/src/barrier.cpp ? The rest of the file is in UNIX format, but that line is DOS. jon -- "The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts." - Bertrand Russell
Jonathan Wakely wrote:
On Wed, Jul 14, 2004 at 11:47:57AM -0400, Michael Glassford wrote:
I certainly hope that Boost.Threads finally settle down in a stable form. The MetaComm results show that it is in such a poor state. http://tinyurl.com/4s58j indicates that not a single test passes. A lot of libraries (including Spirit) rely on this library and time is running out.
Yes, I just noticed this yesterday and was rather surprised: I had expected at least MSVC++ 6 and 7.1 to work, since I tested both of those. It's not in as bad shape as it looks, though, since almost all of the errors are the same:
Cannot open include file: 'boost/thread/detail/config.hpp': No such file or directory
This file is in CVS, and has been included in some files for quite a long time; the change I made was to include it in all files. Apparently I'm missing something, but I don't understand why the file isn't being found.
Is it possible it's the stray DOS newline on line 12 of libs/thread/src/barrier.cpp ?
The rest of the file is in UNIX format, but that line is DOS.
The line ending is an interesting coincidence, but though I've fixed that one (there are others in other files) I'm rather doubtful that it will fix the problem--both because it's failing with this same error on all compilers, including VC++ 6 & 7.1, which work for me, and because Robert Ramey seems to be having a similar problem. In another thread, he says "In reviewing the failure of the serialization library build on Darwin - it seems that none of the include file can be found." I notice that VC++ 7.1, for instance, is being called with the commands: <output> CALL "C:\Program Files\Microsoft Visual Studio .NET 2003\VC7\bin\VCVARS32.BAT" >nul "C:\Program Files\Microsoft Visual Studio .NET 2003\VC7\bin\cl" /Zm800 -nologo -GX -c -DBOOST_THREAD_LIB_NAME=boost_thread -DBOOST_THREAD_BUILD_DLL=1 /Z7 /Od /Ob0 /GX /GR /MDd /Op /Zc:forScope /Zc:wchar_t -I"C:\Users\Administrator\boost\main\results\bin\boost\libs\thread\build" -Fo"C:\Users\Administrator\boost\main\results\bin\boost\libs\thread\build\boost_thread.dll\vc7.1\debug\threading-multi\barrier.obj" -Tp"C:\Users\Administrator\boost\main\boost\libs\thread\build\..\src\barrier.cpp" </output> and that there is no -I switch for the boost header files. Unless that directory is being included by means of the INCLUDE environment variable or some other means, this looks like a problem to me. Mike
Jonathan Wakely wrote:
On Wed, Jul 14, 2004 at 11:47:57AM -0400, Michael Glassford wrote:
I certainly hope that Boost.Threads finally settle down in a stable form. The MetaComm results show that it is in such a poor state. http://tinyurl.com/4s58j indicates that not a single test passes. A lot of libraries (including Spirit) rely on this library and time is running out.
Yes, I just noticed this yesterday and was rather surprised: I had expected at least MSVC++ 6 and 7.1 to work, since I tested both of those. It's not in as bad shape as it looks, though, since almost all of the errors are the same:
Cannot open include file: 'boost/thread/detail/config.hpp': No such file or directory
With help from others, I think I've fixed this too. Mike
The following line in in boost/thread/detail/lock.hpp (line 66), which was just changed yesterday, causes a syntax error on Tru64 unix (cxx). typedef typename Mutex mutex_type; (similar lines also in scoped_try_lock and scoped_timed_lock). AFAIK, we don't need "typename" in this case. Was this inserted as a workaround for a broken compiler??? (Or, Tru64 cxx is broken???) Synge From: Michael Glassford <glassfordm@hotmail.com> Date: Tue, 13 Jul 2004 11:13:30 -0400
Joel de Guzman wrote:
Joel de Guzman wrote:
Joel de Guzman wrote:
g++3.2 on MinGW has some trouble compiling boost/thread/detail/lock.hpp:
../../../boost/thread/detail/lock.hpp:30: semicolon missing after enum declaration
[...]
The same problem is found in thread/read_write_mutex.hpp:37: and thread/detail/read_write_lock.hpp.
Fixed.
*** There are also no newlines at the end of these files. ***
Fixed.
Fixing all those above, Spirit compiles now with only one test failing. The failure is again because of boost.threads (again on MinGW, g++3.2) :
read_write_mutex.cpp: In member function `void boost::detail::thread::read_write_mutex_impl<Mutex>::do_read_lock()': read_write_mutex.cpp:87: parse error before `(' token
read_write_mutex.cpp: In member function `bool
boost::detail::thread::read_write_mutex_impl<Mutex>::do_try_read_lock()': read_write_mutex.cpp:161: parse error before `(' token
read_write_mutex.cpp: In member function `void boost::detail::thread::read_write_mutex_impl<Mutex>::do_read_lock() [with Mutex = boost::mutex]':
read_write_mutex.cpp:621: instantiated from here
read_write_mutex.cpp:98: `l' undeclared (first use this function)
read_write_mutex.cpp:98: (Each undeclared identifier is reported only once for each function it appears in.)
Any hints?
No ideas at the moment.
Mike
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Synge Todo <wistaria@comp-phys.org> writes:
The following line in in boost/thread/detail/lock.hpp (line 66), which was just changed yesterday, causes a syntax error on Tru64 unix (cxx).
typedef typename Mutex mutex_type;
(similar lines also in scoped_try_lock and scoped_timed_lock). AFAIK, we don't need "typename" in this case.
In fact, it's illegal to use typename here.
Was this inserted as a workaround for a broken compiler???
There are no broken compilers I know of that are "fixed" by adding typename where it's illegal.
(Or, Tru64 cxx is broken???)
Nope. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Dear David, From: David Abrahams <dave@boost-consulting.com> Date: Wed, 14 Jul 2004 09:38:19 -0400
In fact, it's illegal to use typename here.
Was this inserted as a workaround for a broken compiler???
There are no broken compilers I know of that are "fixed" by adding typename where it's illegal.
(Or, Tru64 cxx is broken???)
Nope.
Would you kindly fix it, then? Thank you in advance. Regards, Synge
Synge Todo <wistaria@comp-phys.org> writes:
Dear David,
From: David Abrahams <dave@boost-consulting.com> Date: Wed, 14 Jul 2004 09:38:19 -0400
In fact, it's illegal to use typename here.
Was this inserted as a workaround for a broken compiler???
There are no broken compilers I know of that are "fixed" by adding typename where it's illegal.
(Or, Tru64 cxx is broken???)
Nope.
Would you kindly fix it, then? Thank you in advance.
Nope; I'm not the maintainer. Please ask the person who checked in the mistake (cvs annotate will tell you). -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Synge Todo wrote:
Dear David,
From: David Abrahams <dave@boost-consulting.com> Date: Wed, 14 Jul 2004 09:38:19 -0400
In fact, it's illegal to use typename here.
Was this inserted as a workaround for a broken compiler???
There are no broken compilers I know of that are "fixed" by adding typename where it's illegal.
(Or, Tru64 cxx is broken???)
Nope.
Would you kindly fix it, then? Thank you in advance.
Regards, Synge
I've fixed it in CVS. My apologies: I've just recently emerged from the dark ages of MSVC++ 6 (we've finally started moving to MSVC++ 7.1) and will make mistakes like this occasionally until I'm used to more standard-compliant C++. I was lulled into a false sense of security by both MSVC++ 6 and MSVC++ 7.1 accepting the typename. Mike
Dear Dave and Mike, Thank you very much! Synge From: Michael Glassford <glassfordm@hotmail.com> Date: Wed, 14 Jul 2004 11:38:39 -0400
Synge Todo wrote:
Dear David,
From: David Abrahams <dave@boost-consulting.com> Date: Wed, 14 Jul 2004 09:38:19 -0400
In fact, it's illegal to use typename here.
Was this inserted as a workaround for a broken compiler???
There are no broken compilers I know of that are "fixed" by adding typename where it's illegal.
(Or, Tru64 cxx is broken???)
Nope.
Would you kindly fix it, then? Thank you in advance.
Regards, Synge
I've fixed it in CVS.
My apologies: I've just recently emerged from the dark ages of MSVC++ 6 (we've finally started moving to MSVC++ 7.1) and will make mistakes like this occasionally until I'm used to more standard-compliant C++. I was lulled into a false sense of security by both MSVC++ 6 and MSVC++ 7.1 accepting the typename.
Mike
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Joel de Guzman wrote:
Fixing all those above, Spirit compiles now with only one test failing. The failure is again because of boost.threads (again on MinGW, g++3.2) :
read_write_mutex.cpp: In member function `void boost::detail::thread::read_write_mutex_impl<Mutex>::do_read_lock()': read_write_mutex.cpp:87: parse error before `(' token
read_write_mutex.cpp: In member function `bool
boost::detail::thread::read_write_mutex_impl<Mutex>::do_try_read_lock()': read_write_mutex.cpp:161: parse error before `(' token
read_write_mutex.cpp: In member function `void boost::detail::thread::read_write_mutex_impl<Mutex>::do_read_lock() [with Mutex = boost::mutex]':
read_write_mutex.cpp:621: instantiated from here
read_write_mutex.cpp:98: `l' undeclared (first use this function)
read_write_mutex.cpp:98: (Each undeclared identifier is reported only once for each function it appears in.)
I'm pretty sure these are fixed now, though I won't be absolutely certain until the regression tests re-run. I've really got to get gcc / MinGW installed on my machine. Mike
Michael Glassford wrote:
Joel de Guzman wrote:
Fixing all those above, Spirit compiles now with only one test failing. The failure is again because of boost.threads (again on MinGW, g++3.2) :
[...]
I'm pretty sure these are fixed now, though I won't be absolutely certain until the regression tests re-run. I've really got to get gcc / MinGW installed on my machine.
Confirmed. All Spirit tests are passing now on g++3.2 MinGW. Thank you! -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Joel de Guzman wrote:
Joel de Guzman wrote:
g++3.2 on MinGW has some trouble compiling boost/thread/detail/lock.hpp:
.../../../boost/thread/detail/lock.hpp:30: semicolon missing after enum declaration
Easy fix:
enum lock_state { unlocked=0, locked=1 };
and
enum blocking_mode { non_blocking=0, blocking=1 };
Actually, I removed them. According to the recent very long discussions of the locking classes and other things, they won't be used.
It's been a while since I've seen the old constructs such as:
typedef enum { unlocked=0, locked=1 } lock_state;
Sorry, it's an old habit that I slip into when I'm not thinking about it, caused by a broken compiler I used long ago. I changed it in all the other places I could find as well. Mike
Joel de Guzman wrote: [...] Ok... more Boost.Test (minor) problems: http://tinyurl.com/72awd -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Ok... more Boost.Test (minor) problems:
And what is the problem here? Gennadiy.
Gennadiy Rozental wrote:
Ok... more Boost.Test (minor) problems:
And what is the problem here?
It's giving a "fail" flag on Comeau. See the MetaCom test results for Boost.Test. See your basic_cstring_test at http://tinyurl.com/55xg6 for example. Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
IMO, there's nothing wrong with using namespace std; in local scope. Here's a fix:
There is already workaround on top of the file dealing with gcc 3.3. I wonder why is that gcc does not put namely wcscmp into namespace std or why BOOST_NO_STDC_NAMESPACE is not defined? We need to figure out what is going on and then upddate above mentioned workaround. Gennadiy.
Gennadiy Rozental wrote:
IMO, there's nothing wrong with using namespace std; in local scope. Here's a fix:
There is already workaround on top of the file dealing with gcc 3.3. I wonder why is that gcc does not put namely wcscmp into namespace std or why BOOST_NO_STDC_NAMESPACE is not defined?
We need to figure out what is going on and then upddate above mentioned workaround.
You have to figure it out fast. The deadline is nearing. Anyway, the technique I suggested, which we use in Spirit, is better than your trick of hoisting the names into namespace std which is a hack that should be avoided if there are other ways. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
On Tue, Jul 13, 2004 at 03:24:57PM -0400, Gennadiy Rozental wrote:
IMO, there's nothing wrong with using namespace std; in local scope. Here's a fix:
There is already workaround on top of the file dealing with gcc 3.3. I wonder why is that gcc does not put namely wcscmp into namespace std or why BOOST_NO_STDC_NAMESPACE is not defined?
The workaround applies to all versions of GCC 3.3, but I think that wcscmp is missing from std on any GCC version iff the standard library is not configured with wchar support. If libstdc++ is configured without wchar support then there will be no using declarations to pull the wchar.h names into std. Simplified, cwchar looks like this: #include <wchar.h> #if _GLIBCPP_USE_WCHAR_T namespace std { // ... using ::wcscat; using ::wcscmp; using ::wcscoll; // ... } #endif (N.B. for GCC 3.4 and later the macro is called _GLIBCXX_USE_WCHAR_T)
We need to figure out what is going on and then upddate above mentioned workaround.
The workaround should make use of the BOOST_NO_CWCHAR macro, which is set if _GLIBCPP_USE_WCHAR_T / _GLIBCXX_USE_WCHAR_T is not set (see boost/config/stdlib/libstdcpp3.hpp) Maybe something like this (but using BOOST_WORKAROUND): #if defined( __GNUC__ ) && defined( BOOST_NO_CWCHAR ) namespace std { using ::wcscmp; } #endif Although this isn't quite right, as it only tests for GCC, but it's the stdlib that affects the availablity of std::wcscmp (i.e. GCC with STLPort wouldn't be affected AFAICT) jon -- "Once, during Prohibition, I was forced to live for days on nothing but food and water." - W.C. Fields
participants (6)
-
David Abrahams -
Gennadiy Rozental -
Joel de Guzman -
Jonathan Wakely -
Michael Glassford -
Synge Todo