[Development] Regular expression libraries for QRegExp

[Giuseppe D'Angelo]

On 21 November 2011 21:25,  <lars.knoll at nokia.com> wrote:
>>I don't know. We should choose the features we want and then require
>>that.
>>Unicode matching sounds interesting.
>
> As does the JIT. Do you have an idea on how much bigger PCRE gets by these
> features?

On 32bit Linux:

   text	   data	    bss	    dec	    hex	filename
 387691	    728	    176	 388595	  5edf3	libpcre-jit/lib/libpcre.so
 260245	    580	     12	 260837	  3fae5	libpcre/lib/libpcre.so
 159869	    416	     12	 160297	  27229	libpcre-noucp/lib/libpcre.so

First line is with JIT and UCP, second UCP only, third neither of them.
In terms of relocations:

libpcre-jit/lib/libpcre.so: 49 relocations, 23 relative (46%), 61 PLT
entries, 38 for local syms (62%), 0 users
libpcre/lib/libpcre.so: 46 relocations, 23 relative (50%), 27 PLT
entries, 13 for local syms (48%), 0 users
libpcre-noucp/lib/libpcre.so: 17 relocations, 1 relative (5%), 27 PLT
entries, 13 for local syms (48%), 0 users


>>> About the API itself: would you like more three classes (raw pattern
>>> -> compiled pattern -> result of a match), or only two (pattern ->
>>> result of a match)?
>>
>>Two sounds better. I don't see the point in having a distinction between
>>a raw
>>and a compiled pattern. We might just need a pattern class and simply
>>have a
>>method to compile it.
>
> Agree with Thiago.

Ok. My only concern was that const methods of the pattern will have to
compile it (... modify the shared instance) behind the scenes. I'm not
sure if you wanted to get rid of these behaviours (thus, the "compiled
pattern" class).

Cheers,
-- 
Giuseppe D'Angelo