[LLVMdev] Regular Expression lib support

[OvermindDL1]

Blast, LLVM list not filling in the response headers still...

On Sun, Aug 23, 2009 at 6:32 PM, Daniel Dunbar<daniel at zuster.org> wrote:
> On Sun, Aug 23, 2009 at 3:29 PM, Kenneth Uildriks<kennethuil at gmail.com> wrote:
>> On Sun, Aug 23, 2009 at 4:56 PM, Daniel Dunbar<daniel at zuster.org> wrote:
>>> We would like to have access to some kind of regular expression
>>> library inside LLVM. For example, we need this to extend the FileCheck
>>> test case checking tool to support regular expressions.
>>>
>>> There are three obvious options:
>>>  1. Roll our own library. Multiple unnamed individuals may even
>>> already have implementations lying around! :)
>>>  2. Use POSIX regcomp facilities. This implies importing some
>>> implementation of this interface, e.g., Windows. On Linux, BSD, etc.
>>> we would try to use the platform version if available (and non-buggy).
>>>
>>>  3. Import a more heavy weight library such as PCRE, and use it universally.
>>
>>
>> Personally, I'm a big fan of the Boost libraries.  They've got a regex
>> library, and a full-blown parser library (which I am using in my
>> front-end).  It's definitely heavier than POSIX, but it's portable,
>> well-tested, and loaded with features.
>
> This is too heavy, and we don't need the extra features, and regexec
> is well tested and much more standard. Unless there is an overwhelming
> agreement to add another option, I'd like to keep the discussion to
> the obvious choices. That is, I need to be convinced *not* to use #2,
> before I get derailed into discussing which form of #3 to take.

POSIX has a tendency to be rather useless on some major platforms,
notably Windows (which has no built-in regex library), which is why I
still recommend Spirit, it can be as lightweight as you want, you only
pay for what you use, and it works fast and everywhere.
Boost.xpressive is also quite good if you need the dynamic
functionality (you really should not, how often is the grammar/regex
going to be generated at runtime anyway?).