Re: [boost] Re: Regexp code bloat

From: Miroslav Silovic (miro_at_[hidden])
Date: 2002-10-24 04:38:23

Eric Niebler wrote:

>Before you complain about how "bloated" libraries like regex++ and GRETA are
>compared to libs like PCRE, it's important to consider differences in the
>feature sets.  GRETA and regex++ are *generic* template libraries that work
>with any bidirectional iterator type, with narrow or wide characters.  PCRE
>(as far as I know) only works on char*.  Also, regex++ has an extremely rich
>feature set, and GRETA is getting there.  regex++ can work with C++ locales.
>PCRE can't do that.  You buy a lot of functionality with all that "bloat".
>
First, I meant no insult when I used the word 'bloat' - it's just a 
standard term. I apologize if it was misunderstood. Secondly, as 
somebody already posted, none of that functionality is commonly used. 
I'm sure not willing to pay for C++ regexps something that's in the same 
order of magnitude as the entire perl implementation, especially if what 
I want is performance, so here the size does matter.

Furthermore, it seems that a lot of that code can be folded together 
using virtuals - and in this case, fitting everything into the CPU cache 
is well worth the extra function call overhead, IMHO (although this 
could be a good place to benchmark). Or even, folded together by casting 
everything into strings before matching (sucks, but matches the most 
common usage patterns).

>That said, I think GRETA is about as big as regex++.  The GRETA regression
>test compiles to a 570 Kb executable.  That includes instantiations on 4
>iterator types, x2 for different end-of-string policies, x2 for recursive
>vs. iterative engine.  That's a "kitchen sink" configuration -- most people
>only need 1 or 2 instantiations.  Also, I use a trick to fold similar
>
In that case, why isn't 1-2 instantiations the default building mode, 
with add-ons instantiated from headers by applications that need them?

>instantiations, which saves 200 Kb with the VC++ toolset, but which wouldn't
>work with libstdc++ (though it might with stlport).  YMMV.
>