Re: [Boost-users] [spirit] how to get_position() from a multi_pass<position_iterator <const char*> >

Subject: Re: [Boost-users] [spirit] how to get_position() from a multi_pass<position_iterator <const char*> >
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2009-08-21 17:37:12

> On Thu, Aug 20, 2009 at 22:42, Hartmut Kaiser<hartmut.kaiser_at_[hidden]>
> wrote:
> >> I use a position_iterator<const char*> for parsing with
> boost::spirit.
> >>
> >> Because I need the regex_p feature, I have to wrap this iterator
> >> using a multi_pass iterator.
> >>
> >> I call pt_parse and get a
> >>
> >> boost::spirit::tree_parse_info<multi_pass<position_iterator<const
> >> char*> >, ...> parse_info.
> >>
> >> Now I have problems calling the get_position() method on
> >> "parse_info.stop".
> >>
> >> I guess this is the case because multi_pass does not store my
> >> iterator but wraps it using boost::iterator which loses the position
> >> features of position_iterators and only keeps the const char*
> pointer.
> >>
> >> Do you have an advice for me?
> >
> > It's difficult to tell from here as you didn't provide too much
> information.
> > Would you mind posting a small example exposing your problem?
> 
> I have attached a minimal example.
> 
> If you do not define MULTIPASSDBG, it builds but you are not allowed to
> use regex_p in the parser.
> 
> If you define it, you are allowed to use regex_p, but the get_position
> does no longer compile and so the iterator becomes a bit useless.
> 
> I read something about a "base()" method for wrapping iterators, but
> could not find one in the multi_pass sources.

Ok, I understand. But I think your whole approach is not viable. Regex_p requires a bi-directional iterator, while multi_pass exposes an input_iterator only. So generally, even if it compiled it wouldn't work in the end.

But to answer your original question, multi_pass doesn't allow to access the base iterator, which might be an oversight. I'll have a closer look and add it to the multi_pass iterator if possible.

Regards Hartmut

PS: I don't know how long you are using the Spirit.Classic AST/PT code already or whether this is a new project you just started to develop. In any case I strongly suggest to consider abandoning the Spirit.Classic tree parsers and switching to Spirit V2.1 (Boost SVN trunk). This is an interface breaking change, but overall and in the long run preferable. The Spirit.Classic tree code is known to be slow and buggy and I doubt it will be fixed. Spirit 2.1 is much faster, more stable and generally easier to use.