Re: [boost] [spirit] trunk: circular dependency parse <-> construct <-> assign_to (?)

From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2008-05-29 10:50:21

Troy,

> I started playing with spirit-2/lex (on the trunk), specifically
> examples/lex/example4.cpp, thought
> I'd try to parse some python.  I've hit an error that was already asked
> about a month or so ago.

What problem have you hit?

> It appears to be because this guy:
> 
> http://svn.boost.org/trac/boost/browser/trunk/boost/spirit/home/qi/deta
> il/assign_to.hpp
> 
> doesn't have 'construct' overloads for various types (conversion to
> unsigned is the one
> that comes up in the example).  I dug around and found construct.hpp,
> 
> http://svn.boost.org/trac/boost/browser/trunk/boost/spirit/home/qi/deta
> il/construct.hpp
> 
> which does have them, but they forward to parse(), using proto
> placeholders from over in
> support/placeholders.hpp.  This ends up coming round again to
> assign_to.
> 
> At this point I can't decide whether this is going to be detangleable
> or not.
> I thought I'd ask for some hints on what things are supposed to look
> like in the end, if so.   In any event, the code is absolutely
> fascinating.  Time well spent.

It's supposed to work as follows:

- Any parser uses one of the assign_to() overloads to assign it's attribute
value to the specified destination. 
- The assign_to() functions use construct overloads to do the conversion
from an iterator range to the requested type (if appropriate). This
distinction has been made decouple Spirit specifics from the conversion
itself and to allow the user to provide his/her own construct() overloads
for custom parsers (to be found via ADL).
- Some of the (predefined) construct() functions use Spirit parsers
themselves to do the conversion. But here we use only parser primitives
which provide their attributes as (already converted) values, not as
iterator ranges.

I still have a hard time to see your problem. The construct() functions use
qi::parse only for the conversion of iterator ranges to the attribute type,
so there shouldn't be any cyclic dependencies.

HTH
Regards Hartmut