- Boost - lists.boost.org

thread monitor
by Qihong Wang 31 Jan '09

31 Jan '09

Hello, I have a service thread and a monitor thread in my program. Currently I use pthread. The service send and receive data and process it by speech recognition and update DB. Service thread may be hung some where because of a unknown bug. So the service thread update its state to a global activity object. The monitor check the activity object every 30 seconds. If the state of service thread is not idle and the span between updating time and current time is larger than a threshold, then monitor considers service thread is hung and kill it and restart a new service thread. This implementation has at least two flaws. It can't discover thread in hung immediately. It's hard to provide a optimal threshold. Because speech recognition may take short or long time to process different data. I just started to use boost and read some sample code using boost thread. I'm wondering whether I can have a better solution by using boost thread and how to do it? Regards, Qihong

1 0

[date_time] local_date_time noticeably faster than ptime
by oneill1979 30 Jan '09

30 Jan '09

We noticed recently that using a local_date_time in tight loops was several times faster than using a ptime object. As these are both based largerly on the same template code this was a surprise. It appears this is caused by the implementation of the operater+=/-= and was wondering if there was any justification for the difference or if this was just an oversight. .\boost\date_time\local_time\local_date_time.hpp //! Local_date_time += time_duration local_date_time_base operator+=(const time_duration_type& td) { this->time_ = time_system_type::add_time_duration(this->time_,td); return *this; } .\boost\date_time\time.hpp time_type operator+=(const time_duration_type& td) { time_ = (time_system::get_time_rep(date(), time_of_day() + td)); return time_type(time_); } It looks like the ptime implementation is doing extra work to split the ptime into date and time_duration components and if it is changed to follow a similar pattern to that used in the local time the performance is then indistinguishable. time_type operator+=(const time_duration_type& td) { this->time_ = time_system::add_time_duration(this->time_, td); return time_type(time_); } I can only think that maybe this was done to work around an issue and in which case should the same then be applied to the local time implementation? Paul. -- View this message in context: http://www.nabble.com/-boost--date_time--local_date_time-noticeably-faster-… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

[parameter] trunk regression testing broken
by David Deakins 30 Jan '09

30 Jan '09

It appears that a file was missing from the recent commit of the 'literate' tests for the Boost.Parameter library. Our testing computer is reporting the following issue while attempting to run regression tests on the trunk: error: Unable to find file or target named error: 'static-member-functions0.cpp' error: referred from project at error: '../libs/parameter/test/literate' I have temporarily commented out this file in test/literate/Jamfile.v2 until it is added. -Dave

2 1

[1.38][date_time] Permission to merge a trivial fix
by Andrey Semashev 29 Jan '09

29 Jan '09

Am I allowed to merge this change into the release branch? https://svn.boost.org/trac/boost/changeset/50876 This is a trivial fix for missing #include. I ran tests locally, no problems occurred.

2 1

[program_options] option_description::format_name() virtual
by fabien.hinault＠free.fr 29 Jan '09

29 Jan '09

Hello, It would be nice to have option_description::format_name() virtual so that the non-POSIX programs which prefer "/" or "-" to mark options can easily modify the doc of the options by subclassing option_description. Fabien

1 0

[1.38][updated libraries] Releaes Notes
by Daniel James 29 Jan '09

29 Jan '09

Hello library developers, If you've made any changes to your library, and haven't added them to the release notes, you should do so now. You can either add them to the file at: https://svn.boost.org/svn/boost/website/public_html/beta/feed/history/boost… Don't worry too much about syntax, I'll fix it if necessary. Or if that's too much trouble, email them to this list. It's exactly the same drill as the last few releases. If your library has a changelog in your library, and you just want me to pull the changes from that, let me know. thanks, Daniel

8 10

[swap] maintainer
by Daniel James 29 Jan '09

29 Jan '09

Hi, The maintainer for swap is listed as Joseph Gauterin in 'libs/maintainers.txt', but most of the recent changes seem to be by Niels Dekker. So is Joseph still the maintainer? As well as keeping the maintainers list up to date, I need to know so that I can request a trac component for the library. thanks, Daniel

3 2

[scope_exit] documentation
by Alexander Nasonov 29 Jan '09

29 Jan '09

Hi, Daniel James generated documentation for ScopeExit and commited it to trunk: http://svn.boost.org/svn/boost/trunk/libs/scope_exit/doc/html/index.html There are some differences compared to the reviewed version: * New syntax for captures. Some reviewers suggested (ref a)(cref b)(val c) syntax but I implemented (&a)(&b)(c). This syntax is very close to C++0x lambda syntax for captures: [&a, &b, c]. I can add support for const ref/val: (const& b)(const c) but I will not be able to support this syntax after a transition to C++0x. * tutorial has been updated to demonstate pass-by-value. * I've added C++0x to the Alternatives section. Any comments, suggestions etc are welcome. Thanks, Alex

1 0

[math] Multivariate root finding
by Tom Holden 29 Jan '09

29 Jan '09

Is anyone currently working on multivariate root finding in the math toolkit or elsewhere? Anyone know if this is planned? It would be good to have an alternative to GSL. Thanks in advance, Tom

4 4

[Fwd: Re: [format] please add operator String()]
by James Fowler 28 Jan '09

28 Jan '09

Thorsten Ottosen wrote: > ... > I my mind formatting is so closely tied to strings that I don't see > any problem in the implicit conversion. IIRC, String.Format in other > langauages return a String. Is some valid reason for require explicit conversion? It sure would be convenient for format to convert implicitly to string. If there is a valid reason, what about a wrapper class? I've used something close to the following for the last few years, and it hasn't bit me so far : class sformat : public boost::format { public: sformat( const std::string &s ) : boost::format( s ) {} operator std::string () { return boost::str( *this ); } template <class T> sformat & operator%( T v ) { *((boost::format*)this) % v; return *this; } }; - James -- ______________________________________________ James Fowler, Open Sea Consulting 770-714-3124 / james(a)openseaconsulting.com 1486 Surf Court, Marietta, GA, 30066 http://www.OpenSeaConsulting.com -- ______________________________________________ James Fowler, Open Sea Consulting 770-714-3124 / james(a)openseaconsulting.com 1486 Surf Court, Marietta, GA, 30066 http://www.OpenSeaConsulting.com

1 0