From: David Abrahams (dave_at_[hidden])
Date: 2002-10-23 19:03:49
"Andrei Alexandrescu" <andrewalex_at_[hidden]> writes:
> > Before you complain about how "bloated" libraries like regex++ and GRETA
> > compared to libs like PCRE, it's important to consider differences in the
> > feature sets. GRETA and regex++ are *generic* template libraries that
> > with any bidirectional iterator type, with narrow or wide characters.
> > (as far as I know) only works on char*.
> This argument does not hold. We're not in the dark ages of the OO craze when
> everything inherited something with the code bloat and the vtables and
> everything. I'm so glad those days are behind us, but these days are bad as
> well, just for different reasons! :o) Too many emperors walking down the
> streets naked, and too many people do their best to act as if that's oh so
> cool. (That doesn't relate to the topic by the way.)
> If the regular expressions support (via templates) any iterators and any
> character type, yet I use them only with char* and char, then I should get
> about as much mileage as from a library designed for char* and char. Is that
> a reasonable assumption?
> > Also, regex++ has an extremely rich
> > feature set, and GRETA is getting there. regex++ can work with C++
> > PCRE can't do that. You buy a lot of functionality with all that "bloat".
> No; I buy a lot of bloat with that functionality ***I might not need***.
That depends how the library is organized, and how the implementation
deals with linking away unused parts of the library.
> > That said, I think GRETA is about as big as regex++.
> The hundreds of KB still put both libraries in the hugely expensive range.
> At 500 KB, it would frankly border on unacceptability for many real
Again, it depends on the factors listed above. The question isn't how
big the library is, but how much code it neccessarily adds to a given
project which uses a small part of the library.
> Most of the time, I (and I believe other people) need to do the simplest
> parsing tasks, such as date/time, numbers, stuff. Nothing out of the
> ordinary. To get that done, you need to link in a huge library which offers
> you all that esoteric stuff you might not need, or just do your own crappy
> little stuff. I end up doing the latter. Not good.
> Any chance we get rid of this obese code bloat?
> For example, I'm thinking of a layered design that allows the user to choose
> what level of functionality they need by specifying policies.
Depending on lots of factors like how the existing library is
organized and whether the user is linking statically or dynamically,
your suggestion could easily amount to increasing compilation and
linking times, and bloating the total size of resulting applications.
You have to be very careful about drawing conclusions from the size of
a library file. I don't think we have enough data to determine whether
there's a problem yet.
-- David Abrahams dave_at_[hidden] * http://www.boost-consulting.com Building C/C++ Extensions for Python: Dec 9-11, Austin, TX http://www.enthought.com/training/building_extensions.html
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk