Boost logo

Boost :

From: Joel de Guzman (joel_at_[hidden])
Date: 2006-08-14 19:59:01

Andreas Pokorny wrote:
> Hi,
> "Andy Little" wrote
>> "Joel de Guzman" 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
>> 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

     auto csv = int_ >> *(',' >> int_);

or, in the interim:

     BOOST_AUTO(csv, int_ >> *(',' >> int_));


Joel de Guzman

Boost list run by bdawes at, gregod at, cpdaniel at, john at