- Boost - lists.boost.org

[BGL] [pri_queue] [utility] More documentation, examples, and unit tests.
by Cromwell Enage 18 Feb '04

18 Feb '04

I've consolidated the work into <http://groups.yahoo.com/group/boost/files/boost-pending.zip> I saw a pri_queue subfolder in the libs directory. Should priority queue documentation go there? In <boost/graph/graph_concepts.hpp>, a comment on the BufferConcept class implores it to move out of BGL. Will it eventually move to <boost/concept_check.hpp>? Should the documentation accompanying it similarly move to libs/utility, to maintain consistency? I'm also not sure about where boost::queue documentation should go. Fortunately, only two documents mention it: breadth_first_search.html and breadth_first_visit.html. I've added documentation for a new UpdatableBuffer concept, which both mutable_queue and fibonacci_heap currently model. In the spirit of the Buffer concept documentation, only the update() function and its associated time complexity requirement are added. The zip file contains all of my proposed changes. Once again, feedback appreciated. Cromwell Enage __________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools

1 0

boost threads
by John Fuller 18 Feb '04

18 Feb '04

A recent project of mine uses shared queues based on Ted Yuan's producer-consumer code. The producer consumer code has been modified to use timed waits, and in my concurrency directory I provide management for named threads and channels. See http://sourceforge.net/projects/easyasap/

2 2

Update on the Interval library
by Guillaume Melquiond 18 Feb '04

18 Feb '04

Hi, Now that the 1.31 version of Boost has been shipped, I am gradually pushing into the CVS a new version of the Interval library. The main change is the support for conversion between intervals with different base types. I am pushing it gradually in order to follow the evolution of the regression tests. It seems Borland and pre-7.1 Microsoft compilers won't support at all (there was a partial support in the previous versions of the library) the new version since they are not even able to parse the headers. On the other hand, GCC 2.95 doesn't ice anymore with this new scheme (quite strange, isn't it?). All the other compilers seem to quietly support the new version. Except for cwpro8: there is one failure (det.cpp) in the test-suite. Does this compiler have some known problems when dealing with template ordering? And is there some workaround? Regards, Guillaume

1 0

[threads] rw_lock question
by Vladimir Prus 18 Feb '04

18 Feb '04

Hello, I was looking at rw_lock implementation in the thread_dev branch and see that member variable m_num_waiting_promotion is only set in constructor to '0' and then once tested for equality with 1. So, looks like it has no effect at all? Did I miss anything? Note: I'm not yet planning to use rw_lock, I'm just looking at implementation. - Volodya

2 1

[signals] is assertion necessary when no slots connected
by Jody Hagins 18 Feb '04

18 Feb '04

When signalling, with no slots connected, an assertion is raised (if the return type of the slot is not void). For example: boost::signal<void ()> sig; sig(); does "nothing" while boost::signal<int ()> sig; sig(); asserts (if the default combiner is used). I guess that makes sense, because there can be no "combined" return value if there are no slots. However, an assertion seems a bit harsh. I am really not sure what should happen, but maybe an exception is a better alternative, or maybe an alternative interface can define a default value to be returned if there are no slots connected), or maybe something else... Anyway, I guess I was wanting to know why this is the case, and what is the usual method of handling this circumstance. I assume something like: if (!sig.empty()) { result = sig(); } but that just does not look pretty...

3 3

[Type Traits] Deprecating/eliminating is_stateless
by Douglas Paul Gregor 18 Feb '04

18 Feb '04

is_stateless was a mistake. It is poorly defined and of very limited value. The only place it is used in Boost is in Function, where it's interacting badly with the new operator== functionality. I'd like to deprecate it in CVS head, or even outright kill it. Any objections? Doug

2 1

[BGL] [sandbox] new make_random_paths algorithm
by Cromwell Enage 18 Feb '04

18 Feb '04

Changes to <http:://groups.yahoo.com/group/boost/files/bgl_algo/make_random_paths.zip>: * Added loop_erased_random_paths algorithm. (Thanks to Jonathan de Halleux for the research!) * Renamed make_random_paths as ddnw_random_paths, to make it less appealing. * Updated documentation, example, and unit test. Keep those suggestions coming! Cromwell __________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools

1 0

Re: [function] timing trivia
by matt＠finray.com 18 Feb '04

18 Feb '04

I think I found a suitable trick to measure boost::function overhead in release mode on my platform. I'm getting 14-30 nanoseconds consistently now by forcing the result into a volatile double: Results are: -------------------------------------------------------------------------------- looper invasive timing estimate boost_function_call -------------------------------------------------------------------------------- median time = 33.52057416267943 microseconds 90% range size = 2.514354066985641 microseconds widest range size (max - min) = 19.96459330143541 microseconds minimum time = 25.20813397129187 microseconds maximum time = 45.17272727272728 microseconds 50% range = (33.51961722488039 microseconds, 33.52057416267943 microseconds) 50% range size = 0.9569377990413671 nanoseconds -------------------------------------------------------------------------------- looper invasive timing estimate boost_function_call_equiv_with_in_line_source -------------------------------------------------------------------------------- median time = 33.50287081339713 microseconds 90% range size = 2.509569377990427 microseconds widest range size (max - min) = 16.82918660287082 microseconds minimum time = 25.18851674641148 microseconds maximum time = 42.0177033492823 microseconds 50% range = (33.50287081339713 microseconds, 33.50382775119618 microseconds) 50% range size = 0.9569377990413671 nanoseconds Press any key to continue . . . Which is about an 18ns difference. From this code: #define MAX_FN_LOOP 1e4 static double not_empty() { static double sum; static double i; sum = 0.0; for (i = 0.0; i < MAX_FN_LOOP ; ++i) { sum += i * i; } return sum; } inline double boost_function_call( matt::timer& t ) { boost::function< double (void)> fn = ¬_empty; double now; volatile double x = 0; t.restart(); x += fn(); now = t.elapsed(); return now; } inline double boost_function_call_equiv_with_in_line_source( matt::timer& t ) { double now; volatile double x; t.restart(); static double sum; static double i; sum = 0.0; for (i = 0.0; i < MAX_FN_LOOP ; ++i) { sum += i * i; } x = sum; now = t.elapsed(); return now; } If I change the size of the loop to something much smaller, say 1e1, I get a reasonably consistent result now: -------------------------------------------------------------------------------- looper invasive timing estimate boost_function_call -------------------------------------------------------------------------------- median time = 60.28708133971293 nanoseconds 90% range size = 0.9569377990430612 nanoseconds widest range size (max - min) = 2.90622009569378 microseconds minimum time = 60.28708133971293 nanoseconds maximum time = 2.966507177033494 microseconds 50% range = (60.28708133971293 nanoseconds, 61.244019138756 nanoseconds) 50% range size = 0.9569377990430612 nanoseconds -------------------------------------------------------------------------------- looper invasive timing estimate boost_function_call_equiv_with_in_line_source -------------------------------------------------------------------------------- median time = 43.54066985645935 nanoseconds 90% range size = nanoseconds widest range size (max - min) = 34.92822966507178 nanoseconds minimum time = 43.54066985645935 nanoseconds maximum time = 78.46889952153111 nanoseconds 50% range = (43.54066985645935 nanoseconds, 43.54066985645935 nanoseconds) 50% range size = nanoseconds Press any key to continue . . . About a 17ns difference. Pretty consistent with the previous measurement even though the function workload is a couple of orders of magnitude different. I think my quoteable message for Doug would read: <message> The cost of boost::function can be reasonably consitently measured at around 20ns +/- 10 ns on a modern >2GHz platform versus directly inlining the code. However, the performance of your application my benefit from or be disadvantaged by boost::function depending on how your C++ optimiser optimises. Similar to a standard function pointer, differences of order of 10% have been noted to the _benefit_ or _disadvantage_ of using boost::function to call a function that contains a tight loop depending on your compilation circumstances. </message> HTH... Which is where I'll leave it. I think I'm satisfied with my lack of understanding of this trivial trivia now. Regards, Matt Hurd.

2 1

Re: [boost] Re: Future of threads (III)
by Jody Hagins 18 Feb '04

18 Feb '04

On Tue, 17 Feb 2004 22:13:17 -0500 "Hurd, Matthew" <hurdm(a)sig.com> wrote: > > Or zero threads ;-) with an architecture neutral approach. Exactly. The point is that the user of the AO could care less (except maybe for performance reasons, where the locking strategy may be parameterized to eliminate some overhead). -- Jody Hagins Give him an evasive answer.

1 0

RE: [boost] Re: Future of threads (III)
by Hurd, Matthew 18 Feb '04

18 Feb '04

> On Behalf Of Jody Hagins > David Abrahams <dave(a)boost-consulting.com> wrote: > > > > Are ActiveObjects like all objects were in Simula: each running in its > > own thread, with fully asynchronous inter-object communications? > > > Doesn't have to be. An Active Object could actually have a number of > threads doing work on its behalf. > -- > Jody Hagins Or zero threads ;-) with an architecture neutral approach. Regards, Matt Hurd _______________________ Susquehanna Pacific P/L hurdm(a)sig.com +61.2.8226.5029 _______________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

1 0