Subject: Re: [boost] [synapse] Review
From: Gonzalo BG (gonzalobg88_at_[hidden])
Date: 2016-12-13 04:26:21
David Sankel wrote:
> There is an important aspect to this review that I want to call out. A
signal is a "vocabulary type" in that it is pervasive through systems and
frequently used in public interfaces. One of the most important qualities
of a vocabulary type is that there be only one of them.
I just started to follow this review, and sadly I only have experience with
signals, so cannot really comment on whether adding a second signal
type to Boost is a good or a bad thing.
The only argument I can extract from your review is that a signal-type is a
vocabulary type, and Boost should only have a single signal type.
I am missing the why. In particular, since you then argue
> Imagine the confusion if we had one thread-safe shared pointer class
and another one optimized for single threaded usage,
But I do not need to imagine anything here. Rust has a thread-safe atomic
reference counted pointer (Arc) and a non-thread-safe reference counted
pointer (Rc) in its tiny standard library. While I've seen users being
about lots of aspects of Rust, I've never seen anybody confused about
when/how to use Arc or Rc. Both complement very well in practice, and
arguably this design is a perfect example of C++'s "don't pay for what you
> or if we had an suite of different variant types with different tradeoffs
Recently Boost.Hana was accepted into Boost, with its own tuple type,
such that we now have boost::tuple, boost::fusion::tuple, std::tuple, and
So while I agree that having 4 types to do the same thing can be bad, I
would really like to hear why do you think that:
- Boost.Signals2 signal type chose the right trade-offs,
- the trade-offs chosen by Synapse's signal type are not worth the "cost"
having two different signal types in Boost.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk