December 2002 - Boost-users - lists.preview.boost.org

Regex Match() Abortion
by eydelber 07 Dec '02

07 Dec '02

This probably is annoying me to no end. I have a string that I am matching against a pattern called 'sql'. My program tests 'sql' against 14 possible patterns. The patterns are in an array of strings. EVERYTHING works except for the last pattern. And even then, only when the 2nd sub-expression is longer than a certain length. For example, this works: insert into test (one,two,three) values () Through a lot of testing, I have seen that after the comma delimitted list in the second sub-expression surpasses a certain length, then my program gets aborted at the line if(sqlRegex.Match (sql)) { I am running the latest version of boost regex++, and I am running g++ 2.96 on Linux. I ran gdb, and I seemed to have narrowed down the problem to c_str(), but this is not logical. Here is the part of my program: string checks[] = { /* 0 */ "create table (_ID_) (\\(((\\s*,?\\s*(_ID_) (_TYPES_)( not null)?( unique)?( default ((\\d+(\\.\\d+)?)|(\"[^\"] *\")))?( unique)?\\s*)+)\\))", /* 1 */ "show tables", /* 2 */ "drop table (_ID_)", /* 3 */ "show tdb\\.xml", /* 4 */ "desc( table)? (_ID_)", /* 5 */ "alter table (_ID_) add( column)? ((_ID_) (_TYPES_) ( not null)?( unique)?( default ((\\d+(\\.\\d+)?)|(\"[^\"]*\")))?( unique)?( first| after (_ID_))?)", /* 6 */ "alter table (_ID_) drop( column)? (_ID_)", /* 7 */ "alter table (_ID_) add( column)? \\(((\\s*,?\\s* (_ID_) (_TYPES_)( not null)?( unique)?( default ((\\d+(\\.\\d+)?)| (\"[^\"]*\")))?( unique)?( first| after (_ID_))?\\s*)+)\\)", /* 8 */ "rename table (_ID_) (to|as) (_ID_)", /* 9 */ "alter table (_ID_) alter( column)? (_ID_) (set default ((\\d+(\\.\\d+)?)|(\"[^\"]*\"))|drop default)", /* 10 */ "alter table (_ID_) modify( column)? ((_ID_) (_TYPES_)( not null)?( unique)?( default ((\\d+(\\.\\d+)?)|(\"[^\"] *\")))?( unique)?( first| after (_ID_))?)", /* 11 */ "alter table (_ID_) change( column)? (_ID_) ((_ID_) (_TYPES_)( not null)?( unique)?( default ((\\d+(\\.\\d+)?)|(\"[^\"] *\")))?( unique)?( first| after (_ID_))?)", /* 12 */ "alter table (_ID_) rename( to| as) (_ID_)", /* 13 */ "insert( into)? (_ID_)( \\(((\\s*,?\\s*(_ID_)\\s*)+) \\))? values \\(\\)" }; int checksLength = sizeof checks / sizeof *checks; int i; RegEx sqlRegex; for(i=0;i<checksLength;i++) { sqlRegex.SetExpression(checks[i],true); if(sqlRegex.Match(sql)) { break; } } The interesting thing is that the first string, checks[0] is similar to the insert syntax, and when I use a very long string for the create table syntax, it works perfectly fine. Also, I tried just adding another element to checks, just trying, but that didn't work. Also, I had no such problem for the other 12 cases, it only happens with this last insert case. Any help will be greatly appreciated, I have been stuck on this for days!! Thanks, Kevin

5 13

Missing bjam executable
by Jacek Generowicz 06 Dec '02

06 Dec '02

I'm trying to install Boost on Linux, but the bjam executable http://boost.sourceforge.net/jam-executables/bin.linuxx86/bjam.gz seems to be missing. Is this a known problem, or am I missing something obvious ?

2 1

RE: [Boost-Users] object_pool use ordered_malloc ordered_free. wh y?
by scleary＠jerviswebb.com 06 Dec '02

06 Dec '02

> if construct only, and freeall in ~object_pool. i think it is good. Yes. The destuctor of object_pool will call the destructor of each allocated or constructed object that has not yet been deallocated or destroyed. > can i use object_pool to replace 'new delete'? object_pool provides object-based allocation and deallocation, very similar to new and delete. > the destroy is slow. Destroying single objects that were created from an object_pool uses ordered_free, as you discovered. An object_pool will keep its free list ordered, so that it can run through the "list of allocated objects" in O(N) time instead of O(N**2) time in ~object_pool. It's a performance tradeoff with object_pool::destroy; object_pool was designed more for a "allocate a bunch of objects and then destroy all of them" type of scenario. -Steve

2 1

RE: [Boost-Users] Boost.Threads question
by James Zappia 05 Dec '02

05 Dec '02

> Thanks for all you help. I have a few new questions now, though. ;) > Again, I'm a newbie to C++ so this may seem stupid... > > I created a boost::thread object and even though it goes out of scope, > the thread continues to run. > >As it should, and as it's well documented. The boost::thread object is >analogous to a std::fstream, where the file doesn't get deleted when the >object goes out of scope. In other words, it's just a handle to the >actual running thread. Understood. > Also, when passing a class with the > operator() defined to boost::thread, it constructs and destructs the > object several times which seems odd. > >Also well documented, and essential. If this didn't occur, you'd have to >insure the lifetime of the object passed was longer than the lifetime of >the thread of execution (not the boost::thread object, the actual thread >of execution). Understood. > What I'm basically trying to do > is run a thread, have that thread lock a timed_mutex, then do its job. > Then, in main, I try to lock the same timed_mutex and if I can't get a > lock before the time expires, I need to terminate the thread. Below is > the source code and the output generated. My questions are below, after > the output. > > SOURCE: > #include <iostream> > #include <boost/thread/xtime.hpp> > #include <boost/thread/thread.hpp> > #include <boost/thread/exceptions.hpp> > > using namespace std; > > boost::timed_mutex mutex; > > class thread_class > { > public: > explicit thread_class(int sleep): _sleep(sleep) {}; > > void operator()() > { > boost::xtime xt; > > cout << "thread: locking mutex\n"; > boost::timed_mutex::scoped_timed_lock lock(mutex,true); > >Why do you continue to use this syntax? This performs an explicit lock, >not a timed lock. This overload is for two use cases: > >1) Creating an unlocked lock object: > >scoped_time_lock lock(mutex, false); > >2) Creating a locked lock object which later will be unlocked and then >locked again through a timed lock: > >scoped_time_lock lock(mutex, true); >// .. some code >lock.unlock(); >// .. some code >if (lock.timed_lock()) { > // .. some code >} > >Obviously the second use case will be extremely rare. In your case you're >doing neither of these, and you'd be better served just using a simple >scoped_lock. > > boost::xtime_get(&xt,boost::TIME_UTC); > > cout << "thread: sleeping for " << _sleep << " seconds\n"; > > xt.sec += _sleep; > boost::thread::sleep(xt); > > cout << "thread: freeing lock -- goodbye\n"; > } > > ~thread_class() { cout << "thread_class destructed\n"; } > > private: > int _sleep; > }; > > int main( void ) > { > { > cout << "main: creating thread\n"; > > thread_class test(10); > boost::thread thrd(test); > > cout << "main: sleeping for 2 seconds\n"; > sleep(2); > > cout << "main: trying to lock mutex -- waiting 5 > seconds...\n"; > > boost::timed_mutex::scoped_timed_lock lock(mutex,false); > > boost::xtime xt; > boost::xtime_get(&xt,boost::TIME_UTC); > xt.sec += 5; > > if ( lock.timed_lock(xt) ) > { > cout << "obtain lock -- joining thread\n"; > thrd.join(); > } > else > { > cout << "failed to obtain lock\n"; > } > } > >I'd code this as: > >boost::xtime xt; >boost::xtime_get(&xt, boost::TIME_UTC); >xt.sec += 5; >boost::timed_mutex::scoped_time_lock lock(mutex); >if (lock) // or if (lock.locked()) >{ >// etc I assume you mean boost::timed_mutex::scoped_timed_lock lock(mutex,xt) because I don't see a constructor that takes only a timed_mutex. That said, I agree that your way of doing it is better. Above you asked why I continue to use the syntax I do for locking the mutex in the thread. I want to immediately lock it, then in the main thread try to lock it for a finite amount of time. I can't do that with scoped_lock. Perhaps my strategy is wrong. I want to run a thread for only a specified amount of time. I can't afford to block on a join() to wait for that thread to finish. > cout << "main: making sure thread is gone\n"; > >That's what join is for. I realize this is a toy example, but I can't see >a valid reason for coding it this way. All you've done is introduce race >conditions, even if they are conditions you can feel fairly confident will >do what you want. > > sleep(10); > > return 0; > } > > OUTPUT: > main: creating thread > thread_class destructed > thread_class destructed > thread_class destructed > thread_class destructed > main: sleeping for 2 seconds > thread: locking mutex > thread: sleeping for 10 seconds > main: trying to lock mutex -- waiting 5 seconds... > failed to obtain lock > thread_class destructed > main: making sure thread is gone > thread: freeing lock -- goodbye > thread_class destructed > > 1) Why are so many thread_class objects constructed/destructed when > calling boost::thread? > >The number surprises me a little. I'd have expected two copies, knowing >what I do about the implementation and with out carefully evaluating the >code here. But the documentation is clear that the object will be copied >AT LEAST once, and is free to copy the object any number of times. You >need to account for this in your implementation if it matters. Understood. Apologies for not thoroughly reading the doc first. > 2) After the thread object (test) goes out of scope, why does the thread > continue to run? Is it copied when calling boost::thread and run > detached from the main thread? > >I don't know what you mean by "run detached from the main thread", but >yes, test IS copied (but then, you know that based on what you asked in >1). But then, maybe you meant something else. The "thread object" is >actually "thrd" in your code above, not "test". > > 3) Is there a way I can cancel a thread if going out of scope doesn't > stop it? > >Not yet, but there will be. However, I'm not sure that what you want to >do is really to cancel the thread. It's hard to tell from this toy >example. What the application does is run a job (thread) that has a finite amount of time to finish. If it doesn't finish in that time it needs to send an alert and explicitly terminate the thread (because it can't be blocked with a join() unless it knows the thread is done). As stated above, perhaps my strategy of using the mutex to see if a thread ran in a given amount of time is wrong. Hopefully I'm making some sense, if not, I apologies. James >William E. Kempf Info: <http://www.boost.org> Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl> Unsubscribe: <mailto:boost-users-unsubscribe@yahoogroups.com> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

2 1

ublas::matrix debugging values
by Nick Toze 05 Dec '02

05 Dec '02

Hello, I'm using ublas in MSVC6. How do I find out the values of elements of a matrix when debugging? If I try putting for example mat[0][0] in the 'watch' window then it says 'CXX0058: Error: overloaded operator not found'. Thanks in advance, Nick

1 0

[Fwd: [Boost-Users] Deadlocking problems with recursive_mutex on Linux with boost 1.29.0]
by William E. Kempf 05 Dec '02

05 Dec '02

I'm not sure if _XOPEN_SOURCE or _GNU_SOURCE are defined by the configuration headers or not. It does sound to me, however, like things may well be working on Linux properly and we might just have a user error. Again, can I get a test case for this in order to verify precisely what's wrong? Bill Kempf -------- Original Message -------- Subject: [Boost-Users] Deadlocking problems with recursive_mutex on Linux with boost 1.29.0 From: Dan Nuffer <dnuffer(a)sco.com> Date: Thu, December 5, 2002 10:02 am To: wekempf(a)cox.net Hmm, seems yahoogroups won't let me send an e-mail to boost-users, I guess I subscribed with a different e-mail addr, so I'll just send this directly to you. Subject: Re: [Boost-Users] Deadlocking problems with recursive_mutex on Linux with boost 1.2 9.0 From: Dan Nuffer <dnuffer(a)sco.com> Date: Wed, 04 Dec 2002 17:13:15 -0700 To: Boost-Users(a)yahoogroups.com William E. Kempf wrote: >> Hi >> >> I experienced a lot of deadlocking situations when I used >> recursive_mutex on SuSE Linux 8.1. When I analysed this mutex code I found out, that the implementation of recursive_mutex on Linux is based on recursive POSIX mutexes (set with pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE)). Things were getting interesting when I didn't find a man page for this function and I started to suspect Linux not having implemented this mutex type. >> >> The next thing I had done was to disable recursive POSIX mutexes by commenting out the line "#define BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE" in the file boost_1_29_0/boost/config/posix_features.hpp" forcing boost to implement recursive_mutex by itself. > > > > Interestingly enough, the manpages indicate that Linux has a > pthread_mutexattr_setkind_np that does the same thing as > pthread_mutexattr_settype. I'm not a POSIX programmer, so I'm feeling my way around blindly with some of these more esoteric optional and/or new features. I'm not sure how to correctly detect the availability here, and > to configure accordingly. I'll have to research this particular case for a fix. If anyone knows how to fix the configuration here, please speak up. > Linux definitely has the required functions/functionality. See http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/linuxthreads/mutex.c?rev=… However, in the pthread.h header, the stuff is inside of: #ifdef __USE_UNIX98 To activate it, you should #define _XOPEN_SOURCE 500 or #define _GNU_SOURCE before you actually include anything (best to use -D cmd line arg). > One thing that confuses me... how does this even compile on Linux? If the > pthread_mutexattr_settype function is available to the compiler/linker, why on earth would it not function properly? Definately need to do some research. > > Also, if you have a simple test case that reproduces the deadlock it would > be beneficial for you to send it to me for addition to the test harness. > > >> Since then everything is working quite perfectly! >> >> But I'd like to raise some questions: >> * Is my assumption correct that Linux doesn't have a proper support for recursive POSIX mutexes? > > > > It has support, evidently, possibly just not "proper" support. (Or maybe it does have proper support that's just not documented and we have an implementation problem on my end?) > Linux's implementation looks okay to me. However, it not documented in the man pages. If you have any other questions or anything I can help you out with wrt Linux, just let me know. --Dan William E. Kempf Booster (http://www.boost.org) Boost.Threads author

1 0

Deadlocking problems with recursive_mutex on Linux with boost 1.2 9.0
by beat.schaer＠ruag.com 05 Dec '02

05 Dec '02

Hi I experienced a lot of deadlocking situations when I used recursive_mutex on SuSE Linux 8.1. When I analysed this mutex code I found out, that the implementation of recursive_mutex on Linux is based on recursive POSIX mutexes (set with pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE)). Things were getting interesting when I didn't find a man page for this function and I started to suspect Linux not having implemented this mutex type. The next thing I had done was to disable recursive POSIX mutexes by commenting out the line "#define BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE" in the file boost_1_29_0/boost/config/posix_features.hpp" forcing boost to implement recursive_mutex by itself. Since then everything is working quite perfectly! But I'd like to raise some questions: * Is my assumption correct that Linux doesn't have a proper support for recursive POSIX mutexes? * Can I expect that this problem will be solved in a future release of boost? Regards Beat

3 3

RE: [Boost-Users] Boost.Threads question
by James Zappia 05 Dec '02

05 Dec '02

> Thank you, that worked. I see what I was doing wrong. > > One thing I don't understand about the alternative method... > >> boost::try_mutex::scoped_try_lock lock(mutex); // does a try_lock >> while (!lock) { >> cout << "trying..."; >> lock.try_lock(); >> } > > How does "!lock" in the "while (!lock) { ... }" statement determine > whether it's true or false? Does it call a function in the > scoped_try_lock class? (sorry if that's a lame question...) >Hmmm... this doesn't seem to be documented very well. I'll have to fix >that. What it does is invoke operator void*() for a boolean test (this >mechanism also should be updated to use the safe_bool idiom as well). >Alternatively, you could call lock.locked() (which also appears to be >poorly documented). Thanks for pointing out these deficiencies. >William E. Kempf Thanks for all you help. I have a few new questions now, though. ;) Again, I'm a newbie to C++ so this may seem stupid... I created a boost::thread object and even though it goes out of scope, the thread continues to run. Also, when passing a class with the operator() defined to boost::thread, it constructs and destructs the object several times which seems odd. What I'm basically trying to do is run a thread, have that thread lock a timed_mutex, then do its job. Then, in main, I try to lock the same timed_mutex and if I can't get a lock before the time expires, I need to terminate the thread. Below is the source code and the output generated. My questions are below, after the output. SOURCE: #include <iostream> #include <boost/thread/xtime.hpp> #include <boost/thread/thread.hpp> #include <boost/thread/exceptions.hpp> using namespace std; boost::timed_mutex mutex; class thread_class { public: explicit thread_class(int sleep): _sleep(sleep) {}; void operator()() { boost::xtime xt; cout << "thread: locking mutex\n"; boost::timed_mutex::scoped_timed_lock lock(mutex,true); boost::xtime_get(&xt,boost::TIME_UTC); cout << "thread: sleeping for " << _sleep << " seconds\n"; xt.sec += _sleep; boost::thread::sleep(xt); cout << "thread: freeing lock -- goodbye\n"; } ~thread_class() { cout << "thread_class destructed\n"; } private: int _sleep; }; int main( void ) { { cout << "main: creating thread\n"; thread_class test(10); boost::thread thrd(test); cout << "main: sleeping for 2 seconds\n"; sleep(2); cout << "main: trying to lock mutex -- waiting 5 seconds...\n"; boost::timed_mutex::scoped_timed_lock lock(mutex,false); boost::xtime xt; boost::xtime_get(&xt,boost::TIME_UTC); xt.sec += 5; if ( lock.timed_lock(xt) ) { cout << "obtain lock -- joining thread\n"; thrd.join(); } else { cout << "failed to obtain lock\n"; } } cout << "main: making sure thread is gone\n"; sleep(10); return 0; } OUTPUT: main: creating thread thread_class destructed thread_class destructed thread_class destructed thread_class destructed main: sleeping for 2 seconds thread: locking mutex thread: sleeping for 10 seconds main: trying to lock mutex -- waiting 5 seconds... failed to obtain lock thread_class destructed main: making sure thread is gone thread: freeing lock -- goodbye thread_class destructed 1) Why are so many thread_class objects constructed/destructed when calling boost::thread? 2) After the thread object (test) goes out of scope, why does the thread continue to run? Is it copied when calling boost::thread and run detached from the main thread? 3) Is there a way I can cancel a thread if going out of scope doesn't stop it? Thanks again, James Info: <http://www.boost.org> Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl> Unsubscribe: <mailto:boost-users-unsubscribe@yahoogroups.com> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

2 1

boost::function and template member functions
by Markus Werle 05 Dec '02

05 Dec '02

Hi! With the help of ConcreteEvoker I was able to get an (indirect) address for Test::Apply<double>. This address is obtained via automatic template instantiation, so I feel like there must be a way to achiev the same thing without ConcreteEvoker. Any comments? #include <iostream> #include "boost/function.hpp" #include "boost/bind.hpp" struct Test { template <class T> static T Apply(T t1, T t2) { return t1 + t2; } }; template <class T, class OP> struct ConcreteEvoker { static T Apply(T d1, T d2) { return OP::Apply(d1, d2); } }; int main() { boost::function<double (double, double)> test = &ConcreteEvoker<double, Test>::Apply; std::cerr << test(1.0, 2.0) << std::endl; }

2 1

to add a function to the BGL
by Ramón Casero Cañas 05 Dec '02

05 Dec '02

Let's say I've written a function to prune edges of a graph (data structures and methods are those of the BGL), in the typical C-way (declare the function header in a .h file, and write the code in the .c file). Ok, it works, but I'm not fully satisfied. I would like to make it more BGL-like. So I use templates for generic graphs, include concept check lines in my code, and I have to forget about the .h and .c style, as templates behave a little like macros, and you cannot split the declaration and definition in two files. But, is there a better way to do this, like when you add you own internal property to the graph with BOOST_INSTALL_PROPERTY? Regards, Ramón.

1 0