- Boost - lists.boost.org

[signals2][review] Fwd: Signals2 Review
by Stjepan Rajko 03 Nov '08

03 Nov '08

I am forwarding the following review submitted by Jesse Williamson: ---------- Forwarded message ---------- From: Jesse Williamson <jesse(a)mind.net> Date: Sun, Nov 2, 2008 at 5:09 PM Subject: Signals2 Review To: Stjepan Rajko <stjepan.rajko(a)gmail.com> * Do you think the library should be accepted as a Boost library? Yes. * What is your evaluation of the design? Note: I only read the tutorial, and wrote my own examples as I followed along. I think this is a very nicely designed library! I like the collector interface, and the general library behavior. Note: I was going to suggest some syntactic sugar with operator overloading, but when I tried it I quickly discovered that there's a problem in determining the proper return type for something like + or +=. It isn't really needed anyway-- and, I also have since discovered that the documentation already addresses this! * What is your evaluation of the implementation? I did not examine the implementation. For the most part, things worked as I expected after reading the tutorial examples. * What is your evaluation of the documentation? Good! The tutorials are on the whole very good, and I came through them feeling like I had a good working understanding of the library. I have a few suggestions and perhaps issues, which I discuss below in more detail. I would like to see more explit examples in a few of the tutorial examples, especially those concerning connection management. * What is your evaluation of the potential usefulness of the library? Event patterns show up in many applications, and a thread-safe version of the long-standing Boost::Signals library would surely greatly extend its usefulness. * Did you try to use the library? With what compiler? Did you have any problems? gcc 4.2.1 on AMD x86-64, I had no problems using the library, although I did run into a compiler issue with the examples as written in the tutorial, it was fixed in the packaged example file. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I spent a day reading the tutorial and working through the examples. I had few problems writing my own versions of the tutorial programs, and feel like I came out of them with a good working understanding of the library's use. I believe I worked through all of them. * Are you knowledgeable about the problem domain? Kinda. I've used a fair number of event-driven frameworks, but beyond peeking at it, I've never used the Signals library before. My review is from evaluating the tutorial only. --------------- Some comments and thoughts, mostly written as I went through the tutorial. Documentation: ------------- * Perhaps you should point out the location of the FAQ earlier in the synopsis. I found it at the end, but may not have if I'd been in a hurry. * ToC and main page: The first thing that I notice is that I can infer from the original copyright notice that Douglas Gregor's library appears to have been stable for a really long time! Nice work!! * Introduction: Is it really important that we know Signals2 was formerly known as thread_safe_signals? You might consider pointing this out in the introduction text itself, instead, since it becomes redundant and is more-or-less superfluous information. The introduction gave me a clear idea of what the library is for, and the general abstraction it presents. I've worked with a fair number of event-based systems, and so it already sounds like familiar territory and I felt like I got a good sense of what Signals2 is for. Tutorial: -------- * Do we need "beginner", "intermediate", and "advanced"? I'm not sure why I'm cautioned that the tutorial is not meant to be read linearly, especially since the tutorials typically (and expectedly) progressed from basic to advanced material. Readers tend to pick and choose what they need anyway, and it seemed more visually cluttering than anything. I just followed everything linerally, and did not seem to have many problems. On the other hand, if this is essentially how the documentation has been structured for years, it's unlikely there's any need to change it. * Compiler versions and preferred-form table: I wonder if, instead of maintaining a list of which compilers do support the preferred syntax, it would not be easier to just maintain a list of those which do not support it, especially since it looks to be that only broken compilers don't. * Slot ordering examples: In the intermediate example of ordering slots, I wasn't able to change the order my signal was displayed after reading the material a few times. It always came last, no matter what order I added it in. I was able to do it, but it was by using the numeric ordering I'd learned in the beginner section. In my own test program, I tried: // ... GoodMorning gm; HelloWorld hello; Newline nl; sig.connect(gm); // confused as to why this always comes last sig.connect(2, nl); sig.connect(1, hello); sig.connect(0, gm); // ok, clear why this goes first // ... ...after playing around a while, I understood what the intermediate example was explaining, and it made sense. Maybe it's a pitfall of reading the tutorial out of the recommended order, but the beginner section didn't really seem to explain to me clearly that sig.connect() is actually adding groups and not "individual" signals. (Or, perhaps I'm still confused about how it works? :>) The section where we deal with return values just feels to me like a logical extension of the behavior the beginner tutorial has just discussed, rather than as a seperate tutorial with significantly more advanced behavior-- it seemed natural to want to return values next. * Blocking tutorial: I got a suprise playing with the blocking section when an assertion was triggered: // ... boost::signals2::signal<string (string a, string b)> sig; boost::signals2::connection c = sig.connect(&revcatgoat2); if(c.connected()) cout << *sig("a", "b") << endl; // ... { boost::signals2::shared_connection_block block(c); if(!c.blocked()) { cerr << "something is wrong\n"; throw; } cout << "You shouldn't see this: "; cout << *sig("a", "b"); // SUPRISE abort()! cout << endl; } // ...continue, expecting output when block goes out of scope... ...The tutorial didn't say anything about that happening. Perhaps I was misusing the library..? It worked fine when I checked for c.blocked() again before trying to call sig(). * "Disconnecting Equivilent Slots" example: I didn't feel that the example program for "disconnecting equivilent slots" fully illustrated the library concept. Perhaps that should be made more clear in the example by disconnecting via a pointer to the same function, instead of by using the same identifier that was used to connect(), something like: // ... boost::signals2::signal<int (int a, int b), aggregate_values< vector<int> > > sig; sig.connect(&add); sig.connect(&half); // results of half() seen: { vector<int> results(sig(5, 5)); dump(results); } // Disconnect half() by using an equivilent slot: int (*ptr_to_half)(int a, int b) = half; sig.disconnect(ptr_to_half); // results of half() not seen: { vector<int> results(sig(5, 5)); dump(results); } // ... * Connection Management example: I got a small (but pleasant) suprise when I tried out the connection management: { messageSignal deliver; messageReciever *mr = new messageReciever("message reciever one"); deliver.connect(boost::bind(&messageReciever::show, mr, _1)); { messageReciever *mr2 = new messageReciever("message reciever two"); deliver.connect(boost::bind(&messageReciever::show, mr2, _1)); deliver("message"); } deliver("message"); // SUPRISE: no problem } ...after reading the tutorial section, I had expected the second deliver() call to segfault, but instead it worked nicely. I'm not really going to complain about this, but I'd expected something differently from the tutorial's explanation that it was expected to segfault. It seems reasonable to expect this behavior, given the explaination about shared_ptr<>. Indeed, calling delete explicitly produced mangled output. Perhaps extending the example to show an explosion and how track() gets around it would be worthwhile. Also, maybe it would be nice if the signal_type typedef could be included closer to its actual use in the example? * Automatic Connection Example Problem: There seems to be no get() for NewsMessageArea in the automatic connection management example, and the signature with the application operator appears to probably not be correct. I had to use: // Note second parameter to slot_type ctor: deliver.connect(messageSignal::slot_type(&messageReciever::show, mr2, _1).track(mr2)); * Compiler complaint in "Document-View" example: button.doOnClick(&printCoordinates); ...requires: button.doOnClick(&Button::printCoordinates); ...the example included in the package did not have this issue. (I implemented my own in working through the tutorial.) * Comment on "Passing Slots" example: In the "passing slots" example, Button::f() never appears to get bound. A complete example would be nice. ...on the whole, I enjoyed this tutorial and feel like I can star working with the Slots2 libray! Thanks.

1 0

[1.38.0] Open for merging
by Beman Dawes 03 Nov '08

03 Nov '08

The release branch (https://svn.boost.org/svn/boost/branches/release) is open for merging all stable changes from trunk, including bug fixes and major upgrades to existing libraries. Breaking changes should be coordinated via the mailing list with the developers of the other libraries affected. New libraries may be added, but require permission of a release manager. In other words, except for new libraries, merging changes *does not* need permission from a release manager. I.e. just do it! The release schedule: * November 3, 2008: branches/release opens for merging all stable changes, including bug fixes, and major upgrades to existing libraries. Breaking changes should be coordinated with libraries affected. New libraries may be added with permission of a release manager. * December 20, 2008: branches/release closed for new libraries and breaking changes to existing libraries. Still open for bug fixes and other routine changes to all libraries. * January 3, 2009: branches/release closed for major code changes. Still open for serious problem fixes and docs changes. * January 10, 2009: branches/release closed for all library changes except when specific permission given by release manager(s). * January 17, 2009: Beta release target date. Further betas and/or release candidates as feedback dictates . * January 31, 2009: Release ship date. Links relating to this release: * Google Calendar with the release schedule: <http://www.boost.org/development/index.html>. * Release schedule explanation: <http://svn.boost.org/trac/boost/wiki/ReleaseSchedule>. * Release practices for developers: <http://svn.boost.org/trac/boost/wiki/ImprovingPractices>. --Beman Dawes, Daniel James, Eric Niebler, Rene Rivera

1 0

history/version_1_37_0 link broken
by Neal Becker 03 Nov '08

03 Nov '08

The 'release history' link on the top-level boost/index.html is broken (404): http://www.boost.org/users/history/version_1_37_0

2 2

Boost C++ Library Patches (1.36.0) (from C++ Soup! blog)
by Dean Michael Berris 03 Nov '08

03 Nov '08

Hi Guys, I've recently posted some issues to the Boost Trac system. What follows is the content of my post to my blog (http://blog.cplusplus-soup.com/) regarding patches I've submitted. I hope this helps! ---->8--- For those who have been having some trouble getting some libraries to compile nicely in Boost 1.36 using GCC 4.3.2, I have posted some issues (and associatively some patches) to Boost.Date_Time, Boost.Asio, and Boost.System to the Boost Trac installation. I've listed them down here with a short description of what the issue is and what the solution is (and where you can get the patch for Boost 1.36.0). GCC 4.3.2 and stricter identifier restrictions In the past versions of GCC, the following code would pose no problems: namespace ns { template <class T> struct name { }; name<int> name; // error here! } Now however, you'll get an error saying "declaration of 'name' changes the meaning of identifier 'name'". Apparently the fix is trivial which is to give the namespace qualified name: namespace ns { template <class T> struct name { }; ns::name<int> name; // no error anymore } There is some code in Boost.Date_Time (release 1.36.0) which has this problem. The issue is reported as Boost Trac issue #2465. GCC 4.3.2 and stricter member construction requirements Apparently GCC 4.3.2 has a more strict requirement on when a particular member variable is actually initialized or not -- especially when they are used as temporaries in a static function. I'm not sure if this is a compiler bug/feature, but nonetheless Boost.Date_Time's contrained_value template does not explicitly initialize the member 'value_' variable. The trivial fix (which is to default-construct the member variable in the constructor) is available attached to issue #2463. Boost.System's Missing 'get_posix_category' In Boost 1.36.0, Boost.System's get_posix_category function had been removed. For strict backwards compatibility, it has to be put in to let older versions of libraries that use the function to link properly. This has been submitted as issue (with patches attached) #2461. Boost.Asio's 'pipe_select_interrupter' warning Still with GCC 4.3.2, discarded return values turn out to be warned against. There is a function in Boost.Asio's detail implementations that calls '::write(...)' and then ignores the return value -- which throws a warning and causes builds with -Werror to fail. The trivial patch is attached to the submitted issue #2462. Caveats These patches are submitted to the Boost community through the Trac Issue Trackings system. They have not yet been accepted by authors/maintainers at the time of this writing. Like the saying goes, use at your own risk. Just as a reminder, these patches are to be applied to the Boost 1.36.0 release -- Boost 1.37.0 may have some of these issues addressed. If you find have questions about the patches (and don't want to post comments to the blog entry) please contact me directly through dean.berris(a)cplusplus-soup.com. -- Posted By Dean Michael to C++ Soup! at 11/03/2008 05:27:00 AM ---->8--- -- Dean Michael C. Berris Software Engineer, Friendster, Inc.

1 0

Boost C++ Library Patches (1.36.0) (from C++ Soup Blog)
by Dean Michael Berris 03 Nov '08

03 Nov '08

Hi Guys, I've recently posted some issues to the Boost Trac system. What follows is the content of my post to my blog (http://blog.cplusplus-soup.com/) regarding patches I've submitted. I hope this helps! ---->8--- For those who have been having some trouble getting some libraries to compile nicely in Boost 1.36 using GCC 4.3.2, I have posted some issues (and associatively some patches) to Boost.Date_Time, Boost.Asio, and Boost.System to the Boost Trac installation. I've listed them down here with a short description of what the issue is and what the solution is (and where you can get the patch for Boost 1.36.0). GCC 4.3.2 and stricter identifier restrictions In the past versions of GCC, the following code would pose no problems: namespace ns { template <class T> struct name { }; name<int> name; // error here! } Now however, you'll get an error saying "declaration of 'name' changes the meaning of identifier 'name'". Apparently the fix is trivial which is to give the namespace qualified name: namespace ns { template <class T> struct name { }; ns::name<int> name; // no error anymore } There is some code in Boost.Date_Time (release 1.36.0) which has this problem. The issue is reported as Boost Trac issue #2465. GCC 4.3.2 and stricter member construction requirements Apparently GCC 4.3.2 has a more strict requirement on when a particular member variable is actually initialized or not -- especially when they are used as temporaries in a static function. I'm not sure if this is a compiler bug/feature, but nonetheless Boost.Date_Time's contrained_value template does not explicitly initialize the member 'value_' variable. The trivial fix (which is to default-construct the member variable in the constructor) is available attached to issue #2463. Boost.System's Missing 'get_posix_category' In Boost 1.36.0, Boost.System's get_posix_category function had been removed. For strict backwards compatibility, it has to be put in to let older versions of libraries that use the function to link properly. This has been submitted as issue (with patches attached) #2461. Boost.Asio's 'pipe_select_interrupter' warning Still with GCC 4.3.2, discarded return values turn out to be warned against. There is a function in Boost.Asio's detail implementations that calls '::write(...)' and then ignores the return value -- which throws a warning and causes builds with -Werror to fail. The trivial patch is attached to the submitted issue #2462. Caveats These patches are submitted to the Boost community through the Trac Issue Trackings system. They have not yet been accepted by authors/maintainers at the time of this writing. Like the saying goes, use at your own risk. Just as a reminder, these patches are to be applied to the Boost 1.36.0 release -- Boost 1.37.0 may have some of these issues addressed. If you find have questions about the patches (and don't want to post comments to the blog entry) please contact me directly through dean.berris(a)cplusplus-soup.com. -- Posted By Dean Michael to C++ Soup! at 11/03/2008 05:27:00 AM ---->8--- -- Dean Michael C. Berris Software Engineer, Friendster, Inc.

1 0

[timer_scheduler] is there any interest on a timer scheduler library?
by vicente.botet 03 Nov '08

03 Nov '08

Hi, I would like to be able to submit/schedule tasks at a given time (callouts) which could be oneshot or periodics. Something like the_timer_scheduler::schedule_at(t1_, now()+seconds(10)); Is there any interest on this feature? I have started to scketch the interface of the library. Note: I have used timeout because timer already exists in the boost namespace. callout could be also used if this is more clear. Note. This interface do not allow arbitrary callbacks functions. struct timeout; typedef void (*timeout_callback)(timeout&); struct timeout_type { timeout_type(timeout_callback callback); timeout_callback operator()(timeout&); }; struct timeout { timeout(const timeout_type& type); const timeout_type& type; // ... }; // template class that store in addition a context template <typename CTX, timeout_type& TYPE> struct timeout_ctx : timeout { timeout_ctx(CTX* ctx) : timeout(TYPE) , context_(ctx) {} CTX* context() {return context_;} CTX* operator CTX*() {return context_;} protected: CTX* context_; }; // there is a single timer scheduler namespace the_timer_scheduler { void schedule_at(timeout& handle, system_time& absolute_time); void reschedule_at(timeout& handle, system_time& absolute_time); void schedule_at_periodicaly(timeout& handle, system_time& absolute_time, duration_type period); void reschedule_at_periodicaly(timeout& handle, system_time& absolute_time, duration_type period); void cancel(timeout& handle); } Example: static const timeout_type t1_type; struct my_ctx, typedef timeout_ctx<my_ctx, t1_type> t1; struct my_ctx { my_ctx() : t1_(this) {} t1 t1_; void on_t1(); static void on_t1(timer* p) { static_cast<t1*>(p)->context()->on_t1(); } void funct() { the_timer_scheduler::schedule_at(t1_, now()+seconds(10)); // ... the_timer_scheduler::cancel(t1_); } }; timeout_type t1_type(ctx::on_t1); The implementation of the timeouts scheduler could be based on "Redesigning the BSD Callout and Timer Facilities" by Adam M. Costello, George Varghese http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=B5202FC949FF3EDB0E… Vicente

2 2

[threads] adopt_lock_t question
by Jens Finkhäuser 03 Nov '08

03 Nov '08

Hi! I've come across something that puzzles me. I've got code that, condensed to relevant parts, looks like this: recursive_mutex m; lock_guard<recursive_mutex> l1(m); lock_guard<recursive_mutex> l2(m, adopt_lock_t()); What happens is that if -DNDEBUG is set, the code passes. But if -DDEBUG is set, l1's destructor aborts. Further investigation shows that the destructor calls the mutexe's unlock() function (as expected), which in turn tries to unlock it's internal mutex object - in my case a pthread mutex. The difference between the compilation modes is that the return value of that unlocking function is wrapped in a BOOST_VERIFY(), i.e. assert() call. As I understand the documentation, my code is perfectly valid. It may not make a large amount of sense to use adopt_lock_t as the nature of recursive_mutex should be to not block in l2's constructor - but that's a different matter. Now according to the documentation, lock_guard expects a Lockable, recursive_mutex is a Lockable, and Lockable's unlock() specifies very clearly what sort of conditions need to be met for the function to work: Precondition: The current thread owns *this. Effects: Releases ownership by the current thread. Postcondition: The current thread no longer owns *this. Throws: Nothing So there you have it, in my case the current thread does not own *this after l2's destructor ran - in fact, no thread does. Now there are a two inconsistencies here: 1. The code works fine with other Lockable implementations, such as non-recursive boost mutexes. 2. The behaviour is different depending on compilation mode. Yes, that's the idea behind asserts, but parts of the documentation suggest one behaviour is to be expected, other parts suggest the other is. From that I must draw the conclusion that either recursive_mutex and the unlock() documentation is broken, or the non-recursive mutexes are. Now conceptually, I'd expect unlock() to always succeed. That is, if it's postcondition can be fulfilled, it should always, regardless of compilation mode, exit cleanly. In that case the precondition docs should read something like "*this is either owned by the current thread, or by no thread at all.". I find that to be the case especially for recursive mutexes, as they're intended to be locked/unlocked multiple times in the same thread (though, technically, the calls should always be balanced). All of this is with version 1.35.0, but the docs for 1.36.0 don't seem to be different in the relevant areas. Maybe I'm missing something vital here. If so, I'd greatly appreciate any insight you guys might have. (Incidentally, I find it very hard to disable BOOST_VERIFY with a BOOST_DISABLE_ASSERTS define. I'll have to dig deeper where the re-enabling of asserts sneaks in, but on some machines that has no effect, on others it solves my particular problem, regardless of how correct or incorrect it might be.) Thanks, Jens

2 4

new libaray Boost.Fiber in vault
by k-oli＠gmx.de 03 Nov '08

03 Nov '08

Hello, I've added Boost.Fiber to the boost vault. The library implements lightweight threads of execution (context swapping; fibers on Windows). regards, Oliver

5 14

[1.37.0] Release package final QA
by Beman Dawes 03 Nov '08

03 Nov '08

The 1.37.0 release packages are up at http://boost.cowic.de/rc/ There will be a hold of several hours for last minute QA checks before these get pushed out to SourceForge. In the meantime, if anyone spots any showstoppers, please let us know right away! Thanks, --Beman

3 3

[MultiIndex] "Compatible Sorting Criterion"
by David Abrahams 02 Nov '08

02 Nov '08

The docs mention that the definition is cumbersome. I think you could probably do much better with a formulation that relies on the concept of being partitioned with respect to a predicate function. See www.open-std.org/jtc1/sc22/wg21/docs/papers/2001/n1313.html and the wording changes (now in the standard) at: http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#270 -- Dave Abrahams BoostPro Computing http://www.boostpro.com

2 2