In general, I view signals2 as an update to the signals library. As a long time (happy) user of signals, the only issues I am concerned with are the modifications/changes compared to signals. With the exception of 'trackable', the library interface has changed very little in signals2; all of my signals code still in use has been ported to signals2 with very little difficulty. On Saturday 01 November 2008 03:22:49 pm Stjepan Rajko wrote:
* What is your evaluation of the design?
The design is very similar to that of the existing signals library. As a long time stable library, I am happy with the design. My major concern is that shared_ptr is required for tracking: making shared_ptr work with other custom smart pointers (required at many shops) is an extra step that can be tedious. However, I do not see any other way to avoid the pre-destruction problem mentioned in the documentation without making the interface considerably more complex.
* What is your evaluation of the implementation?
I did not look at the implementation. I am unhappy about the switch to a header-only implementation. Some of my platforms have very little memory into which I have to shoehorn multiple applications; boost.signals is one of the 3 or 4 libraries that is used in multiple applications and the prospect of increasing the overall memory footprint worries me a lot. This problem is not confined to signals2, of course. As a side rant, this tendency to make everything header-only makes life harder for those of us who work with embedded systems; it is hard enough to overcome historical prejudices against C++ in embedded systems without adding perceived "code bloat" to the mix. My only hope is that the CMake-based build sytem becoming a first class citizen of boost would make building easy enough that build issues would no longer be a factor in the decision to make libraries header only. (bjam, while somewhat nice, is used by no other libraries that I use while cmake is used by quite a few and is familiar to a lot of my colleagues.)
* What is your evaluation of the documentation?
The documentation is pretty good. The main gripe is that the meaning of thread safety provided by signals2 over signals is not clearly stated.
* What is your evaluation of the potential usefulness of the library?
The library is very useful; the lack of thread safety has been a long time issue with boost.signals.
* Did you try to use the library? With what compiler? Did you have any problems?
I have used signals2 (actually thread_safe_signals) for a while now on Linux (gcc 4.2.x and 4.3.x on x86_64, gcc 4.1.2 on i386). Compilation issues have been fixed pretty quickly by Mr. Hess.
* How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?
tss/signals2 has been used in production code for several months. However, I have not used the automatic tracking mechanism in a large application and the changes therein have not affected my code significantly.
* Are you knowledgeable about the problem domain?
Reasonably well as a user. I have used Qt's signal/slot mechanism and have been a long time user of boost.signals.
And finally, every review should answer this question:
* Do you think the library should be accepted as a Boost library?
Yes. Regards, Ravi