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