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

Threads - suggestion for producer/consumer pattern - msg_queue (was ThreadPool)
by Oliver.Kowalke＠infineon.com 07 Nov '05

07 Nov '05

Hello, the email with the 'ThreadPool' subject requested an implemention of the synchronization channel between producer and consumer threads. I've a suggestion (adopted from several books) - the only problem is how to tell the consumer threads, that all producer have finished their jobs. You can signal it from outside (deactive member function) or each producer thread has to register on the message_queue (and unregister if it has finished its job). With best regards, Oliver <<test.cpp>> <<message_queue.h>>

1 0

When will boost::socket library issue?
by huangruiguang＠kingnet.biz 07 Nov '05

07 Nov '05

1 0

Translating an absolute path to a path relative to the current directory
by Hermann Rodrigues 06 Nov '05

06 Nov '05

Hi, I am running into the following problem these days: I need to translate an absolute path to a path relative to the current directory on Windows. The translation process need to include all required ".." directory specifiers in the path to make sure it can be accessed from the current directory. The following path samples may clarify the problem. -------------------------------------------------------------------------------- Current Directory: C:\x\y\z Absolute Path: C:\x\y\z\k\w.txt Translated Path: k\w.txt (C:\x\y\z is a common parent) Current Directory: C:\x\y\z Absolute Path: D:\a\b\c\d.txt Translated Path: D:\a\b\c\d.txt (no common parent found) Current Directory: C:\x\y\z Absolute Path: C:\x\k\w.txt Translated Path: ..\..\k\w.txt (C:\x is a common parent) -------------------------------------------------------------------------------- Is there any built-in support in the boost filesystem library to achieve such translation? At first I thought the path::relative_path could solve my problem but it does not seem to take into account the current directory, only the path itself. Any sugestion? Thanks in advance. Hermann

2 2

Re: [Boost-users] [date-time] posix timezone string
by Stering Wolfram 04 Nov '05

04 Nov '05

[I am receiving this list in digested form, so this reply might not be correctly "linked" to its parent, I am afraid.] On Thu, 03 Nov 2005 13:25:07 +0100, Stering Wolfram wrote >> I am implementing a year_based_date-derived date generator to >> calculate the easter sunday for a given year. Now, this is the easy >> part, and it is done already. > Great! >> But I wonder how to generate a meaningful posix timezone string that >> is expected to result from calling the generator's to_string() member. >> >> The documentation at the (not well formatted, b.t.w.) "Description" >> section of class posix_time_zone didn't give any hints for Easter >> Sunday either. >> >> Any ideas? > I'm afraid I need a bit more context -- are you trying to generate a > local_time? In general I wouldn't think you would care about local_time for > Easter? Perhaps a bit of code to show what you want to do? No local_time, just a boost::gregorian::date should be generated, like partial_date for example. So, here we go: What I want to achieve is something like the following: - ----------------------------------------------- // Use the Gauß Formula easter_sunday<date, GregorianEasterSundayGauss> es_gauss; // Use Oudin's Formula easter_sunday<date, GregorianEasterSundayOudin> es_oudin; partial_date pd( 16, Apr ); date d1 = es_gauss.get_date( 2006 ); // 2006-Apr-16 date d2 = es_oudin.get_date( 2006 ); // 2006-Apr-16 date d3 = pd.get_date( 2006 ); // 2006-Apr-16 assert( d1 == d2 ); assert( d1 == d3 ); // But, of course: date d4 = es_gauss.get_date( 2007 ); // 2007-Apr-08 date d5 = pd.get_date( 2007 ); // 2007-Apr-16 assert( d4 != d5 ); - ----------------------------------------------- with easter_sunday<> being defined as follows, modeled after other year based generators (from date_generators.hpp) with the policy defining the algorithm used to actually calculate the easter sunday date for a given year, which differs for the gregorian calendar (catholic, protestants) and the julian calendar (orthodox). The policy could be expected to provide an operator()( year ) which returns an easter_sunday::date_type, for example. - ----------------------------------------------- template <typename date_type, typename policy> easter_sunday : public year_based_generator<date_type> { public: typedef date_type::calendar_type calendar_type; typedef date_type::year_type year_type; easter_sunday() {} // does not require any arguments. virtual ~easter_sunday() {} virtual date_type get_date( year_type y ) const { return _generator_alg( y ); } virtual std::string to_string() const { return "easter_sunday"; /* or what? */ } private: policy _generator_alg; }; - ----------------------------------------------- One remaining glitch is the typedef, as exists for the other generators to pull in the name into the gregorian namespace (gregorian_types.hpp), which is not possible for the policy-based easter_sunday, as a partial template specialization typedef would be required... It would be nice to just say easter_sunday<GregorianEasterSundayGauss> for example, being able to leave out the boost::gregorian::date. A possible modification could be to change the (compile time) policy-based implementation to use a function pointer in the constructor to set the algorithm to be used (kind of Strategy pattern) at run time. Ah, yes, my original question actually was the to_string() which, according to the documentation of year_based_generator, is expected to return a string for use in a POSIX time_zone string. regards, -wolfi -- DI Wolfram Stering (Entwicklung) HALE electronic GmbH., Salzburg, Austria Tel: +43 (662) 439011 550 Fax: +43 (662) 439011 9 Email: wolfram.stering(a)hale.at

2 1

Re: [Boost-users] Threads (Not Mutex) Docs?
by Phil Endecott 04 Nov '05

04 Nov '05

> 1. Start at http://www.boost.org/doc/html > 2. Click on 12. Boost.Threads > 3. Click on Header <boost/thread/thread.hpp> in the contents > 4. Click on the "class thread;" link > > This seems pretty intuitive and perfectly acceptable to me. I replied to Merrill's question because I recognised the difficulty of finding this documentation as something that I had encountered, and continue to encounter from time to time. I suspect that those of you who have been using it for longer have got used to the way that it is organised and do consider it intuitive, but that it not how it has seemed to at least a couple of us "outsiders". Once located the Boost documentation is always good and very often excellent. This makes it a particular shame if it remains hidden. The particular problems that I've encountered are: - The "documentation" link on the front page at boost.org is in a smaller font even than the body text, and is not obviously a link. - The "automatic redirection failed" messages that appear all over the place are disconcerting. - The links to the actual class documentation, e.g. the "class thread;" link in (4) above, are not obviously links. - Links within the documentation often seem to be missing. For example, on the "Chapter 12 Boost.Threads" page, after the "Introduction" heading it looks as if a link is missing before the word "allows". Similarly after the heading "Runtime libraries" something seems to be missing between "using" and "must". Cheers, --Phil.

1 0

Re: [Boost-users] Threads (Not Mutex) Docs?
by Merrill Cornish 04 Nov '05

04 Nov '05

Matt, >>> 1. Start at http://www.boost.org/doc/html >>> 2. Click on 12. Boost.Threads >>> 3. Click on Header <boost/thread/thread.hpp> in the contents >>> 4. Click on the "class thread;" link >>> >>> This seems pretty intuitive and perfectly acceptable to me. I just went back to www.boost.org to double check. I couldn't find any link from the home page to any www.boost.org/doc/* page. This is the case where the first step is the biggest. Now that I know it's there, I can find links to it from a couple of levels down under the documentation link that initially takes you to the lib directory. Also, I had done much of my looking in the various doc directories of the Boost 1.33.0 download tree. Under the top-level doc/html directory there is a threads directory [note the plural] which should be named mutexes, since that's all it covers. There is also a thread directory [note the singular] which, I assume, is supposed to be a copy of what the people who responded to my question referred to on the web site. However, it has only the acknowledgements.html, build.html, and configuration.html files. Merrill

2 1

Re: [Boost-users] Threads (Not Mutex) Docs?
by Merrill Cornish 04 Nov '05

04 Nov '05

Someone needs to go into http://www.boost.org/doc/html and add a link to thread.html. The only thread-related link there now is to threads.html, the mutex treatise. There is no hint there about the other links I've now been given. Thanks, Merrill

2 1

Re: [Boost-users] Threads (Not Mutex) Docs?
by spam_from_boost_users＠chezphil.org 04 Nov '05

04 Nov '05

> Where is the documentation of Boost Threads--not mutexes, threads? http://www.boost.org/doc/html/thread.html

2 1

Re: [Boost-users] boost::condition questions
by Adam M 04 Nov '05

04 Nov '05

Ok, I see now in scoped_lock the following: operator const void*() const { return m_locked ? this : 0; } So, in wait() where they check "if( !lock) {...}", they're actually checking to see if the lock has locked the mutex. However, for the reasons I mentioned in my earlier post, this still seems perilous. Can someone explain? Thanks, Adam

1 0

boost::condition questions
by Adam M 04 Nov '05

04 Nov '05

Hi, I have a couple questions regarding boost::condition. You can view the condition.hpp here: http://www.boost.org/boost/thread/condition.hpp 1) wait() starts out as follows: -------------------------------- void wait(L& lock) { if (!lock) throw lock_error(); ... -------------------------------- This "if (!lock)" seems to be checking if the lock is NULL, not if the mutex is actually locked. In the documentation, it says: "Throws: lock_error if !lock.locked()" However, even this seems to be a bit dubious, because that checks to see if the given lock is the one that locked the mutex, and *not* if the mutex itself is locked. Remember that the scoped_lock constructor can take a second parameter to indicate whether or not to actually lock the mutex. One might use this as an alternative to recursive locking, so that a synchronized function may call another synchronized function and indicate with a flag that the scoped_lock "initially_locked" parameter should be 'false'. If that function then called to wait(), lock.locked() would return 'false', when the mutex is in fact actually locked. Am I wrong? 2) In the boost::condition documentation: http://boost.org/doc/html/condition.html #4 on "condition waiting" is wrong; they left out the boost::xtime parameter. Thanks, Adam

1 0