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
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
