Boost logo

Boost :

Subject: Re: [boost] [synapse] Review
From: David Sankel (camior_at_[hidden])
Date: 2016-12-13 20:38:55


On Tue, Dec 13, 2016 at 4:26 AM, Gonzalo BG <gonzalobg88_at_[hidden]> wrote:

> David Sankel wrote:
>
> > 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
> boost::hana::tuple...
>

I don't think this is a good situation! Hana had other merits that
compensated for the drawback of introducing another tuple type. Many
organizations avoid Boost for unfortunate situations just like this.

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,
>

In sum, I think the Boost.Signals2 model is easier to understand and use
for the common case. They work a lot like function pointers, which are
familiar, and the storage model is straightforward to explain.

- the trade-offs chosen by Synapse's signal type are not worth the "cost"
> of
> having two different signal types in Boost.

I didn't find a strong motivation for having another signals library with
this design in the documentation nor could I come up with it on my own. I
could be convinced that we really need this with some compelling motivation
though notwithstanding the interface issue I raised.

-- David


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