- Boost - lists.boost.org

[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

Future of threads (III)
by scott 17 Feb '04

17 Feb '04

hi y'all, i have been listening-in to the recent thread thread (intentional); its worth it! threading is a special interest for myself at the moment. i have been working on something different (distributed messaging) and have been forced to consider threading. again and again. it seems to be impossible to address the one (messaging) without also addressing the other (multi-threading). this would come as no real surprise to anyone, but the slightly unnerving thing has been the "distance" between the threading model that seems to fulfil the requirements of my distributed messaging and the model in boost::threads. this is not intended to question the validity of that model; quite the opposite. i have wondered if my model is invalid and considered the task of "porting" the messaging code to the boost model (if not the implementation) calling it the "boost model" seems a little unfair as i think i can say it is in the spirit of other implementations such as rogue wave's. recent work has taken me on a different path. i have been cornered into applying my messaging+threading model within a significant body of complex production code. millions of lines of code and dozens of threads. the interesting thing (for me :-) has been how effectively the new threading model has integrated with the existing model(s). this did make me feel better about the track i had taken. so, is there room for 2? very briefly, the boost model treats threads as a resource (fair enough to :-) and submits code fragments for asynchronous execution. in the alternate model, threads come about as a consequence of instantiating final (a la java) objects. the distinguishing attribute being that threads only run code that is "part of themselves" rather than code being submitted from "outside". execution of the code is initiated by sending of a message (within my vocabulary that is actually a signal). the message can contain arbitrary data. is this different enough? is there enough value there? cheers, scott

11 33

Perfect Forwarding (almost)
by David Abrahams 17 Feb '04

17 Feb '04

The example below shows a technique for perfect forwarding that seems to work with GCC 3.3.1. rvalues are always moved automatically, and lvalues are copied. Except for one rather important case, it works with Comeau (errors only in strict mode). The important case that causes the error clearly violates 12.2/1 of the standard, but see below. VC++ and CodeWarrior have different kinds of problems with it from Comeau/strict. I am hoping that they are wrong, but I am not enough of a core language jock to make a determination on which of these compilers is correct (if any). 12.2/1 says that the act of binding an rvalue to a (const) reference creates a temporary (which may be elided). The creation of the temporary requires the existence of a copy ctor with a const& argument. As far as I know, that rule serves no useful purpose, but I may have missed something. *If* my example actually works other than this case, I'd like to try to get the rule lifted, and soon! This is by no means the cleanest route to move semantics, but it's probably the smallest "language extension" we'd ever need to get it, and might even be possible before C++0x Enjoy, Dave -- Dave Abrahams Boost Consulting www.boost-consulting.com

14 70

RE: [boost] Re: Moving Boost.Thread barrier from thread_dev to HE AD
by Bjorn.Karlsson＠readsoft.com 17 Feb '04

17 Feb '04

> From: Michael Glassford [mailto:glassfordm@hotmail.com] > One potential problem that I am aware of is that it is > possible for the > m_generation counter (see barrier.cpp) to overflow on systems that > detect overflow of integer addition instead of wrapping (I > assume there > are such systems though I've never used one). Is it > worthwhile checking > for this and forcing wrapping in code? Checking for overflow isn't needed in this case, since the underlying type is unsigned (and unsigned integer arithmetic does not overflow [per §3.9.1.4]). Bjorn

2 1

Re: boost thread static library
by Arkadiy Vertleyb 17 Feb '04

17 Feb '04

Thanks, Russell and Michael, from your responces I realise that I will probably have to leave with DLL. However, the next question then would be why am I getting these undefined refs while linking with boost_thread-mgw-mt-d-1_31d? obj\synchronizer.o(.text$_ZN5boost9condition7do_waitINS_5mutexEEEvRT_+0x29):sync hronizer.cpp: undefined reference to `boost::detail::condition_impl::do_wait(__p thread_mutex_t**)' obj\synchronizer.o(.text$_ZN5boost6detail6thread8lock_opsINS_5mutexEE4lockERS3_R NS3_8cv_stateE+0x14):synchronizer.cpp: undefined reference to `boost::mutex::do_ lock(boost::mutex::cv_state&)' obj\synchronizer.o(.text$_ZN5boost6detail6thread8lock_opsINS_5mutexEE6unlockERS3 _RNS3_8cv_stateE+0x14):synchronizer.cpp: undefined reference to `boost::mutex::d o_unlock(boost::mutex::cv_state&)' Thanks, Arkadiy _________________________________________________________________ Get fast, reliable access with MSN 9 Dial-up. Click here for Special Offer! http://click.atdmt.com/AVE/go/onm00200361ave/direct/01/

2 1