Rainer Weikusat <rweikusat@talktalk.net> writes:

> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>
> [...]
>
>> Personally I think that writing bulky procedural stuff for
>> something like [0-9]+ can only be much worse, and that further
>> abbreviations like \d+ are the better direction to go if targeting
>> a good interface. YMMV.
>
> Assuming that p is a pointer to the current position in a string, e
> is a pointer to the end of it (ie, point just past the last byte)
> and - that's important - both are pointers to unsigned quantities,
> the 'bulky' C equivalent of [0-9]+ is
>
> while (p < e && *p - '0' < 10) ++p;

To force the comparison to be done as unsigned:

while (p < e && *p - '0' < 10u) ++p;

Kaz Kylheku <643-408-1753@kylheku.com> writes:

> Here is an example: using a regex match to capture a C comment /* ... */
> in Lex compared to just recognizing the start sequence /* and handling
> the discarding of the comment in the action.
>
> Without non-greedy repetition matching, the regex for a C comment is
> quite obtuse. The procedural handling is straightforward: read
> characters until you see a * immediately followed by a /.

Regular expressions are neither greedy nor non-greedy. One of the
key points of regular expressions is that they are declarative
rather than procedural. Any procedural change of behavior overlaid
on a regular expression is a property of the tool, not the regular
expression. It's easy to write a regular expression that exactly
matches a /* ... */ comment and that isn't hard to understand.