Andreas Pokorny wrote:
Hi,
"Andy Little" wrote
IIUC, the "rule" specifies the result type (not deduces the result type). I think it's not a macro at all; it would rather be something like: "unspecified_type", or "you-define-your-type-here-and-ill-do-the-rest" Well again I am probably not understanding it fully, but from one of Andreas
"Joel de Guzman" wrote posts higher in the thread:
get_result_type<add_tag,LeftT,RightT>
presumably could be implemented as:
template <typename LeftT, typename RightT> struct get_result_type<add_tag,LeftT,RightT> { typedef BOOST_TYPEOF_TPL(LeftT() + RightT()) type; };
That would be a hen-egg situation. The result_type of the operator is defined by the rules, not the other way around. Like the Joel said, the encoding of the expression tree into operator and function return types is up to the user.
The frontend of the DSLs built with this framework consist of overloaded operators (already provided by the framework), and small user defined inline functions (probably created using a framework macro). These functions invoke the rule system with the operands, and an operator tag which identifies the function or operator. The result type is deduced by finding a matching rule, the result (value) is returned after calling a static method inside the rule found.
So the user might even refuse to encode the expression inside a rule, but evaluate the expression directly and return the result of the evaluation.
Right. But then again, the ET framework will always benefit from typeof/auto: auto csv = int_ >> *(',' >> int_); or, in the interim: BOOST_AUTO(csv, int_ >> *(',' >> int_)); Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net