Re: [boost] Re: Regexp code bloat

From: John Maddock (jm_at_[hidden])
Date: 2002-10-25 06:40:28

> > what you need, and code size should be in the 100K range (it depends a
bit
> > on which traits class you use - if you start using std::locale then code
> > size can go up quite a bit).
>
> That's more like it, but still a 2x away from what would be (imho)
> acceptable.

That was an off the top of my head guess, after some experimentation I got a
minimal boost.regex app down to 56K:

#define BOOST_REGEX_STATIC_LINK
#include "boost/regex.hpp"

int main(int, char**) {
      boost::regex abc("abc");
      std::string s("abc");
      boost::regex_match(s, abc);
      return 1;
}

That's with boost.regex statically linked but with the dynamic C/C++ runtime
with VC7.

> > I suppose I should refactor into multiple shared libs, but IMO that's a
> > maintenance nightmare: I'm not saying it won't happen, just that it's
not
> as
> > trivial as it sounds :-(
>
> Yup. Let me point out that it's much more useful than
>
> > Finally there is one problem here: because regexes are interpreted
> strings,
> > you pay for every feature you might use, not for those that you actually
> do
> > use.  User feedback up until now has been driving towards more features
> not
> > less, on the other hand you could probably put together a very basic
> > toy-regex implementation in about 10K, IMO it's use would be very
limited
> > though.
>
> Not what I think. If you're like me, most of the time you have simple
> parsing needs. Heck, I've parsed my tax data with a couple of simple
rules.
>
> True, many will have more complex needs. The point is that users should
pay
> for what they need, not the whole thing at once. This could be achieved by
> compiling versions with limited feature sets, even though the regex is
> interpreted. As things stand right now, the two mamooth regexp libraries
are
> a perfect motivator for regular programmers (heh, that's a pun) to roll
> their own.

I accept that you can do it with preprocessing, but then you get into
endless arguments about which subset, not to mention the testing headaches
that are caused by multiple sub-set configurations.  Grief, it's bad enough
supporting complex things like this as it is... not saying it won't happen,
but it requires very careful thought.  Is a 50K overhead really that bad?

John Maddock
http://ourworld.compuserve.com/homepages/john_maddock/index.htm