On 21 November 2011 21:25, <[email protected]> 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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
