[boost-users][regex] Failure with minimal example on GCC 4.3.1
I'm not sure if I'm missing something here, but I think this is a bug. I'm trying to compile the following with gcc4.1.3 on Ubuntu 7.10: $ g++ -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.1.3 --program-suffix=-4.1--enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2) #include <boost/regex.hpp> int main() { using namespace boost; std::string str; regex re("."); cmatch what; regex_match(str, what, re); return 0; } GCC doesn't manage to find the right overload of regex_match and says only this: lala.cpp: In function 'int main()': lala.cpp:11: error: no matching function for call to 'regex_match(std::string&, boost::cmatch&, boost::regex&)' /usr/local/src/boost/trunk/boost/regex/v4/regex_match.hpp:80: note: candidates are: bool boost::regex_match(const std::basic_string<charT, ST, SA>&, boost::match_results<typename std::basic_string<charT, ST, SA>::const_iterator, Allocator>&, const boost::basic_regex<charT, traits>&, boost::regex_constants::match_flag_type) [with ST = std::char_traits<char>, SA = std::allocator<char>, Allocator = std::allocator<boost::sub_match<const char*> >, charT = char, traits = boost::regex_traits<char, boost::cpp_regex_traits<char> >] It compiles fine if you instead pass str.c_str() as the first argument. On the other hand, If you explicitly qualify the regex types with boost::, gcc spews out the attached misery-ball. AFAIK, these all work on msvc9. Is the example above supposed to work? Cheers, Darren
Darren Garvey wrote:
I'm not sure if I'm missing something here, but I think this is a bug.
GCC doesn't manage to find the right overload of regex_match and says only this:
lala.cpp: In function 'int main()': lala.cpp:11: error: no matching function for call to 'regex_match(std::string&, boost::cmatch&, boost::regex&)' /usr/local/src/boost/trunk/boost/regex/v4/regex_match.hpp:80: note: candidates are: bool boost::regex_match(const std::basic_string<charT, ST,
&, boost::match_results<typename std::basic_string<charT, ST,
const_iterator, Allocator>&, const boost::basic_regex<charT, traits>&, boost::regex_constants::match_flag_type) [with ST = std::char_traits<char>, SA = std::allocator<char>, Allocator = std::allocator<boost::sub_match<const char*> >, charT = char, traits = boost::regex_traits<char, boost::cpp_regex_traits<char> >]
It compiles fine if you instead pass str.c_str() as the first argument. On the other hand, If you explicitly qualify the regex types with boost::, gcc spews out the attached misery-ball. AFAIK, these all work on msvc9.
Is the example above supposed to work?
Nope: different iterator types: cmatch supports const char* iterators, but basic_string::const_iterator isn't necessarily that type (though sometimes it is, depending on the platform/compiler). You should be using boost::smatch as the match_results type when searching a std::string. HTH, John.
Hi John, On 22/11/2007, John Maddock <john@johnmaddock.co.uk> wrote:
Darren Garvey wrote:
Is the example above supposed to work?
Nope: different iterator types: cmatch supports const char* iterators, but basic_string::const_iterator isn't necessarily that type (though sometimes it is, depending on the platform/compiler). You should be using boost::smatch as the match_results type when searching a std::string.
Oh dear, I should have seen this. Thanks for the help. HTH, John. Cheers, Darren
I just recently installed and built boost library (1.34.1) using bcbboost. I wanted to try the boost::thread class. This simple code gives me "Access Violation" in Borland C++ Builder 2006 when boost::mutex is used: //-------------------------------------------------------------------------- - #include <iostream> #include <boost/thread.hpp> //-------------------------------------------------------------------------- - boost::xtime xt = {2}; boost::mutex console; // line A void thr() // int n, boost::mutex & display { for (int i = 0; i < 10; i++) { { boost::mutex::scoped_lock l(console); // line B std::cout << "thr" << 1 << ":" << i << std::endl; } boost::thread::sleep(xt); } // end for } int main(int argc, char* argv[]) { boost::thread_group tg; tg.create_thread(&thr); char c; std::cin >> c ; return 0; } If line A and line B are commented-out then the error is gone. The project is a multithreaded console application, both boost.threads and rtl are static-linked. Caller stack is: :7c812a5b kernel32.RaiseException + 0x52 :004129aa ___raiseDebuggerException + 0x1A :00412a84 ; ___raiseDebuggerException :7c9037bf ntdll.RtlConvertUlongToLargeInteger + 0x7a :7c90378b ntdll.RtlConvertUlongToLargeInteger + 0x46 :7c90eafa ntdll.KiUserExceptionDispatcher + 0xe :0041FA2B boost::mutex::do_unlock(this=NULL, =:0012FDE8) :0041E3A2 boost::detail::thread::lock_ops<boost::mutex>::unlock(m=NULL, state=:0012FDE8) :0041E12D boost::condition::do_wait<boost::mutex>(this=:0012FEA4, mutex=NULL) :0041DE2E boost::condition::wait<boost::detail::thread::scoped_lock<boost::mutex>
(this=:0012FEA4, lock=:0012FE5C) :0041D42F __UNNS__thread_01c827c2c2c9169a::thread_param::wait(this=:0012FE9C) :0041D201 boost::thread::thread(this=:00000FCC, threadfunc=:00000FC8) :00000001 :0012fe01
I put mutex.cpp in my directory and BCB2006 locates the error to be here: void mutex::do_unlock() { if (m_critical_section) //------------- Access violation HERE release_critical_section(m_mutex); else release_mutex(m_mutex); } The access violation is raised when thread::thread constructor is called. Looking at the caller stack I noticed that mutex parameter is NULL from some point and it results in this==NULL for the last call. Note that this mutex parameter is not the mutex "console" object I use in the program. It is a mutex that boost.threads library uses during thread initialization. On the other hand there is some dependance on mutex "console" because when I comment it out the error is gone. I maked console a pointer with appropriate changes to source and created it using new but it did not help. Am I missing something? Any help appreciated. Does anybody have experiences with boost::thread and mutex under BCB(2006,2007...)? Vaclav
participants (3)
-
Darren Garvey -
John Maddock -
v2cechura