From: Eugene Lazutkin (eugene.lazutkin_at_[hidden])
Date: 2002-10-26 10:27:21
"Peter Dimov" <pdimov_at_[hidden]> wrote in message
> Strange discussion. It is obvious that the best custom code matching
> requirements can never be larger or slower than generic code with a large
> user base matching a wider set of requirements. If you try to design a
> "regex lite" it will inevitably evolve into something very similar to
> Boost.Regex or GRETA, unless you ignore user feedback, in which case the
> library will be ignored by the users.
Nobody says bad words about regex++/Greta functionality. The discussion is
about library structure. It is highly desirable to implement any universal
library in such way that user pays only for used functionality. Imagine that
you decided to use addition and subtraction in your program and got linked a
solver for all kinds of differential equations. It can be a problem for some
I think that it would be extremely rare to see project, which uses 100% of
regex++/Greta functionality. From my experience usually I need some
relatively small pieces of functionality. I believe that majority developers
are like me in this respect. Some can live with code bloat. Some don't. I
did some stuff for Inet and portables and size does matter for my users.
Now, is it possible to reduce size of said libraries? I don't know. It is up
to esteemed authors of respective libraries to decide. Maybe it is not
possible is this particular case.
My position is simple:
1) Cooperation Principle
1a) user should not pay for unused functionality
1b) real project uses several libraries, the only practical way to reduce
code bloat is #1a
2) Library Scope
2a) each good library has well defined area of expertise it covers
2b) logically area of expertise consists of smaller subareas
2c) #2b provides foundation for library structure
3) Developer Needs
3a) majority of developers need just a subset of library to implement simple
3b) it is pretty rare that all functionality of any given libraries is used
in single project
3c) see #1b and #1a
If library implement #2 without #1, it will not satisfy #3 in most cases.
The result is simple: great library is not going to be reused, and we will
re-invent the wheel once again.
If it is not possible to go away from "kitchen sink" approach because of
some inherent complexities, layered approach can be used. The simplest form
is to have several (two?) related versions of the same library: full-blown
universal one and slim simple one. If parsing pattern string takes a lot and
requires to link some dead code --- get rid of it in simplified version! I
would be happy to construct my static patterns in some other way!
Anyway this is just my 2c. Feel free to do with it whatever you want. :-)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk