Boost logo

Boost :

Subject: Re: [boost] [signals2][review] The review of the signals2 library (formerly thread_safe_signals) begins today, Nov 1st
From: Ravi (lists_ravi_at_[hidden])
Date: 2008-11-19 08:20:40


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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk