[boost] Re: Regexp code bloat

From: Andrei Alexandrescu (andrewalex_at_[hidden])
Date: 2002-10-23 22:02:41

"Eric Niebler" <neric_at_[hidden]> wrote in message
news:ap7jaf$g6j$1_at_main.gmane.org...
> The OP is refering to compiling regex++ into a separate shared lib.  If
you
> want a lib, you have to pay for every feature you could possibly use.

Ah, now I get it. Still, a couple of separate pre-built libraries wouldn't
hurt: for char and for wchar_t and for using pointers as iterators.

> Certainly if you're willing to go with the inclusion model, then you can
do
> much better.  But the inclusion model is expensive because regex
> implementations are non-trivial.  It takes gcc a full 5 minutes (on a dual
> PIII 550) to compile GRETA's implementation at /O3.  Putting all that in a
> header is just not an option.

Makes sense. I wonder how Spirit gets away with that. Then, the stl itself
is non-trivial and it gets included all the time.

Plus, you can put the declarations only in the header and have the client
instantiate the template externally.

> That's for a "kitchen sink" configuration.  I just compiled a little regex
> exe on my machine that uses GRETA with just 1 instantiation, and it weighs
> in at 150 Kb.

That's not bad, yet Spirit boasts sizes in the 25KB range. And that includes
the iostreams!

>   (And there's are some things I can do to cut that in half, but
> there are only so many hours in a day.  :-)

Wonderful. Anyone can say it can't be done. An expert finds a way to do it.
(Does that sound corny?)

> Definitely possible, if you're willing to write and maintain many
different
> regex engines and all the interactions between the different policies.

The point is to find orthogonal features that allow you to achieve
combinatorial effects. I'm not sure if it can be done, but then I'm just
anyone and not a regex expert (see above :o)).

> > The main limitation is that you can't specify
> > patterns at runtime, which most re users don't need anyway.
>
> IMO, this is critical functionality.  Without it, you couldn't use a regex
> engine to write a grep-like utility, or a text editor with regex search,
or
> a log parsing tool.  These are all uses people have found for GRETA, and
> regex++ I'm sure.

Oh sure. But on the other hand the format of date and time, or the format of
HTML files, the format I want to coerce user input into, the format of
protocols (HTTP, FTP, IMAP, POP...), all these don't change at runtime.
Again, it depends on what software you are writing.

> There is usablity to consider, also.  Specifying a regex as a string is
much
> easier and more terse than writing an expression template, particularly if
> you have to chose policies to "turn on" certain feaures of your regex
engine
> and know which headers you need to include to get those features.

True.

> What would be ideal is to have an engine that came with two parsers -- one
> runtime string parser, and one compile-time expression-template parser
> (assuming you didnt have to pay for one if you didn't use it).  This is a
> direction I have been planning on taking GRETA, but I've only just begun
to
> play with the code.  It's a tricky problem, but I'm convinced it's doable,
> and worth the effort.

Cool! You may want to cooperate with Joel. Which kinda puts me in the
proverbial vicar's situation :o).

Andrei

--
All new!  THE C++ Seminar: Oct. 28-30 in Vancouver, WA.
http://www.thecppseminar.com/