Maurizio Vitale wrote:
thanks, it sure helped a lot.
In my case I had to wrap proto::terminal inside a my_domain<> wrapper. This was required with the simplified code I posted, but I'm mentioning it for the benefit of others trying to learn proto.
Do you mean to say this was *not* required with the simple code you posted?
I still have a couple of issues: - although udt_ex(v) is now parsed, udt_ex(v1,v2) is not.
The following program compiles for me. I suspect the problem you're seeing is not in proto. #include <boost/xpressive/proto/proto.hpp> struct udt_tag {}; boost::proto::terminal<udt_tag>::type const udt = {{}}; int main() { udt(1,2); return 0; } I've tried
to #define BOOST_PROTO_MAX_ARITY to be 2, but this also doesn't seem to work (and if debug.hpp is included you get an ambiguous overload between debug.hpp:122 and rlocal.hpp:775.
I don't know what rlocal.hpp is. It is not a proto header. I suspect some other code you're including is interfering. I'm interested to see how. The ambiguity goes away
with numbers larger than 2). (anyhow BOOST_PROTO_MAX_ARITY seems to be defined to 5 in proto_fwd.hpp)
- with your suggestion, when an object of class udt_ex is encountered in an expression, the corresponding node in the parse tree has a udt_tag.
Yes.
In my case udt contains additional data, not only extra methods and types. What is a good way for getting that information into the parse tree?
Put the data in udt_tag. Then rename udt_tag to udt_data or some such. Is specializing
as_expr going in the right direction? Basically, I'd like something like var/val in the lambda.cpp test, but without having to explicitly decorate expressions.
But you say above that you're already wrapping expressions. I'm confused. Maybe you could say a bit about your use case. Do you only want your udt terminals to have the extra data and members, or all expressions? -- Eric Niebler Boost Consulting www.boost-consulting.com