|
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