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

On Fri, Aug 21, 2009 at 23:37, Hartmut Kaiser wrote:

...

...

...

I use a position_iterator 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 >, ...> 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*

On Thu, Aug 20, 2009 at 22:42, Hartmut Kaiser wrote: 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.

I see, obviously I did not read the documentation closely enough, I just found out that it states regex_p requires a bidirectional iterator and multi_pass exposes a forward iterator. Nevertheless the combination multi_pass/regex_p compiled and worked fine for me. regex_p even worked fine with only the position_iterator (until you changed the position_iterator iteration type) which made it no longer compile with regex_p. (I used regex_p in the first place because lexeme_p included leading whitespace (which is really a nuisance to me), regex_p does not create this issue).

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.

Thank you for this. I wonder if it would be possible to create some multi_pass like iterator which allows regex_p to be used with a position_iterator (both are very handy tools and it is quite of sad that they cannot be used together). Is there a solution to this in Spirit V2.1? Nevertheless thank you a lot for your work on spirit, it is great! :) Regards, Peter