Re: [jamboost] Re: scanner interface limitations

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-12-02 03:32:15

On Wednesday 01 December 2004 15:45, David Abrahams wrote:
> Vladimir Prus wrote:
> > I think the problem is that
> >
> > 1. We can't mark a specific group in regexp as "unimportant". In
> > Perl/Python, regexp can have "non-capturing paranthesis",
> >
> > >>> r = re.compile("(?:foo|bar)(.*)")
> > >>> m = r.match("foo10")
> > >>> m.group(1)
> >
> > '10'
> >
> >
> > but I don't think bjam's regexps support that
> >
> > 2. Bjam passes only the first matched parenthesised group to the scanner.
> >
> > Looks like your hack is the simplest solution.
>
> I'm not sure it will work, though :(. Are you?

Yes. The bjam code allows several regexps to be specified. It tries all of 
them, and for those which match, adds first matched group to the list of 
strings which is passed to header rule.

I've just checked (on example/customization), that two regexps work.

> The most proper solution would be to provide an additional (outer)

What's 'outer'?

> virtual function in the scanner class that can be used to get more
> control over exactly what gets examined when scanning. It might be
> neccessary to change the bjam core to do that, though. And maintaining
> scanning speed is important there.

Yes, speed could be a problem, so we must be carefull.
BTW, if we make bjam return all matched groups, it will affect C, which uses 
this regexp.

"#[ \t]*include[ ]*(<(.*)>|\"(.*)\")" ;

which has three groups (two of them nested), so we'll get tree strings for 
each include. 

Doing this property requires profiling, so maybe you could try specifying 
three regexp in the meantime?

- Volodya