search for: xpressiv

...,match_extra); if(successful) { float f; vector<int> &i_list = myPair.second; f = atof(m[1].c_str()); myPair.first=f; for(int i = 2; i < what.captures(2).size(); ++i) { i_list.push_back(atoi(m.captures(2)[i])); } } return successful; } boost::xpressive(dynamic): // this uses the same back-end as std/tr1/boost::regex, except you can freely mix-n-match dynamic and static xpressive regex's, so refer to std/tr1/boost::regex boost::xpressive(static): // This will be faster then all of the above methods as the regex parse tree is created at comp...

On Aug 23, 2009, at 5:50 PM, OvermindDL1 wrote: > On Sun, Aug 23, 2009 at 6:32 PM, Daniel Dunbar<daniel at zuster.org> > wrote: >> 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 > > 'regexec' I had never heard of, figured it was a library, turns

OvermindDL1 wrote: > Again, why not Spirit2.1, works just fine on C++98, and it is fast, > and it is split up into the smallest bits so you only include what you > use, and the assembly it compiles into is *very* tiny, far far less > then any regex library could possibly be. > Spirit is not an option for one simple reason: FileCheck needs to parse regexes from its instruction

Hello LLVM Devs, I thought I'd weigh in on some of these non-backtracking linear time RegEx algorithms. If they're anything like the PackRat parsing algorithms they take at least 4x the amount of memory in terms of storage as the string length itself by not backtracking. That should be fine for small RegExes but it wouldn't do so well for more elaborate and long expressions. If

...ly. > > > 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. Boost.Xpressive supports both dynamic and static regex's, what that means is that you can use a regex dynamically (as a string), or you can create it statically (by building up the AST in a *very* easy-to-use way). Honestly, I prefer Boost.Spirit though, which is a PEG parser, it is pure static and it compil...

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.

On Aug 23, 2009, at 9:01 PM, Daniel Berlin wrote: >> 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). > > Don't do it. > They are ridiculous slow, and posix made some really dumb choices in >

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