Proto for Boost mailing list page: Re: [proto] Problems with unary function node

Subject: Re: [proto] Problems with unary function node
From: Eric Niebler (eric_at_[hidden])
Date: 2011-10-28 01:30:36

On 10/22/2011 3:02 PM, Mathias Gaunard wrote:
> On 10/18/2011 05:53 AM, Eric Niebler wrote:
>> On 10/12/2011 2:24 PM, Mathias Gaunard wrote:
>>> There seems to be a significant problem with the unary function node
>>> (and by that I mean (*this)() ) generated by proto::extends and
>>> BOOST_PROTO_EXTENDS_USING_FUNCTION().
>> <snip>
>>
>> Sorry for the delay, and I'm afraid I don't have news except to say that
>> this is on my radar. I hope to look into this soon. But if someone were
>> to beat me to it, that'd be pretty awesome. :-)
> 
> I don't think it can really be fixed in C++03.
> In C++11 though, it's pretty easy, you can just make it a template with
> a default template argument.

It should already be "fixed" for C++11 because operator() uses variadics
if they're available. It's been that way for a while. But in
investigating this problem, I've found that the copy assign operator can
cause the same problem, and that can't be "fixed" this way, even in C++11.

Regardless, I'm convinced that a complete fix is possible, and I have it
mostly coded. It would require you (the user) to disable unary function
and assign in your domain via a grammar. But. It's expensive at compile
time, and everybody pays. I need to be convinced before I proceed. Your
example code was very contrived. (Certainly you don't need to ask a
Proto expression extension type whether it is a proto expression. The
answer will always be yes.) So what is your realistic usage scenario?
What type categorization do you want to do on the extension type that
you can't do on the raw passed-in expression?

Thanks,

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com