Date: 2001-11-28 18:04:53
--- In boost_at_y..., Douglas Gregor <gregod_at_c...> wrote:
> The Signals library has been updated; the new version is at:
> Changes in this version include:
> - Fixes for MSVC and Borland C++
> - Added Documentation: design rationale & comparisons with other
> slots implementations.
> - signal connection now meets the strong exception guarantee
> - Jamfile fixes for building the "bindable.cpp" test
> - combined transform_iterator, skip_if_iterator, and
> into a single slot_call_iterator to reduce template depth and
A couple of comments:
* Under the Rationale, delegates are not C# specific. They are
a .NET concept available to all .NET aware languages (this includes
MC++, managed C++). I'd change the header to read ".NET delegates"
instead (with appropriate changes to the text as well).
* I generally dislike forcing inheritance on users when you don't
have to. It can cause too many problems with the classic diamond
shape heirarchy, and working around this can often be a huge pain.
When possible I now prefer to use generic code to achieve the same
thing with (slightly) less impact. I'm not necessarily suggesting
this be done here as I've not studied any of the implications in this
design, I'm just suggesting that rationale for the choice to use
inheritance may be appropriate to document.
* signalN.html only mentions first_argument_type and
second_argument_type. If there's three arguments is the third type
third_argument_type? How do you manage to define these names through
macro magic? Or is this a documentation error?
* Even though I *think* I understand the rationale, I think you need
to add documentation for why bindable copy semantics (both copy
constructor and assignment operator) result in non-exact copies, i.e.
they disconnect all current connections and don't copy the connection
state of the RHS.
I haven't been able to look at the implementation in depth, which
isn't going to be easy any way because of the macro magic used (not
that I think the macro magic should be removed!). However, I do like
what I've read in the documentation and I'm very glad to see this
concept submitted for inclusion in Boost. For me this rounds out the
concepts needed for "function object" usage, though some Lambda style
creation semantics can still simplify some things for users.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk