[boost] Re: Re: Re: Re: Re: Regexp code bloat

From: Eugene Lazutkin (eugene.lazutkin_at_[hidden])
Date: 2002-10-26 16:05:14

"William E. Kempf" <wekempf_at_[hidden]> wrote in message
news:1358.192.168.1.1.1035649305.squirrel_at_frodo.kempf-ville.com...
>
> Again, this is the crux of the matter.  To quote, you have a "static
> pattern", and for that, a RegExp engine is not ideal.  If you have a mix
> of static and dynamic patterns, then you may want to keep with a RegExp
> engine for both... though a static parser will still be more efficient.

I would not be surprised if our code repeats parts of said libraries. The
big difference for me that regexp++/Greta are made by people who dedicated a
lot of efforts to write them, it is reviewed and debugged, while hand-made
code is just wasted time of some poor programmer, who spend time to
understand problem, and created specialized unusable piece of code. I want
to use standard/well-established libraries but "kitchen sink" approach
doesn't allow to do it in some cases.

> The point is, I still don't see
> any relevant arguments that Boost.RegExp is bloated.

I don't make this argument. But it was not suitable in case I described
before.

Just to understand you completely: what argument will prove to you that some
code is bloated? Complete recreation of (possibly wrong) design ideas with
smaller footprint? How do you want to measure footprint? LOCs, FPs, Ks of
compiled code? If you prefer the latter, do you want to select processor
architecture, compiler, and compiler options? :-)

I think that "code bloat" should be decided on per project basis. I do think
that "full regexp functionality" in 50k is very good. I do think that many
applications can benefit from functionality provided by these libraries. I
don't think that majority of applications will use _all_ functionality. I do
think that "pay as you go" is better than "kitchen sink" approach.

Thanks,

Eugene