Subject: Re: [boost] [yap] Review
From: Zach Laine (whatwasthataddress_at_[hidden])
Date: 2018-02-13 19:14:20
On Tue, Feb 13, 2018 at 1:51 PM, Steven Watanabe via Boost <
> On 02/13/2018 09:47 AM, Zach Laine via Boost wrote:
> > On Tue, Feb 13, 2018 at 11:30 AM, Steven Watanabe via Boost <
> > boost_at_[hidden]> wrote:
> >> On 02/12/2018 06:57 PM, Zach Laine via Boost wrote:
> >>> On Mon, Feb 12, 2018 at 4:15 PM, P F via Boost <boost_at_[hidden]>
> >>> wrote:
> >>>> You could also get rid of the need for `::user_expr`
> >>> We actually want that. It's often necessary to be able to return an
> >>> expression created from some template different than the template
> >> defining
> >>> he operator.
> >> If that's really important then why doesn't
> >> BOOST_YAP_USER_FREE_BINARY_OPERATOR take two
> >> expr_template parameters?
> > Because there's only one result. The expr_template parameter governs
> > the result is constructed, not which inputs are accepted.
> Doesn't this make BOOST_YAP_USER_FREE_BINARY_OPERATOR
> unusable, since expression already uses it, so using it
> again with a different ExpressionTemplate would be ambiguous?
Sure, if you use both of them. I expect people only to use expression for
quick-and-dirty small-scale uses of Yap, or for experimentation though.
However, the same problem exists if I have ET1 and ET2 that want to use
BOOST_YAP_USER_FREE_BINARY_OPERATOR. In that case, the same ambiguity
exists. The solution is the same as any operator overload ambiguity, I
think: sfinae. If there's not already an appropriate constraining macro to
replace BOOST_YAP_USER_FREE_BINARY_OPERATOR (I'd have to look around a
bit), I should add one. *TODO*
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk