From: Daryle Walker (dwalker07_at_[hidden])
Date: 2003-06-28 03:12:53
On Friday, June 27, 2003, at 1:27 PM, Paul A. Bristow wrote:
> I also have an updated ('C++ 1998 STL standardized') version of James
> Kanze's of filtering streambuf and filtering streams derived from his
> files at www.gabi-soft.fr re-built for MSVC 7.1, (Could be posted on
> request).
>
> and his illuminating articles in C++ Report 1998 (attached).
I've read them before. Couldn't you just provide an URL?
> There are also several examples of Inserting (decorating - not sure
> this term is an improvement) and Extracting on input, and some tests
> (though not Boost style test suite, a possible TODO item).
I think the "decorating" term comes from some famous programming book
(nicknamed "Gang of Four" or "GOF", don't know real title).
[SNIP list of James Kanze's examples]
> Sadly I didn't spot much documentation or examples of Daryle's quite
> complex code, which looks to have quite a lot in common with this code
> that Larry Evans is threatening to use. (More sadly, I was much
> impeded in trying to understand much of Larry's work in progress on
> account of the bizarre layout - this would be an serious impediment to
> acceptance by Boosters - see the Boost coding guidelines?)
[TRUNCATE]
Please note that the code I gave is UNFINISHED. That is why there is
no documentation or examples. The crux of this library, the virtual
filtering functions, haven't been written yet! I posted the code
because I was looking for suggestions on what the virtual filtering
functions should be.
1. Most of the similar code I've seen has been specific input- or
output-filtering examples (like Larry's), or general input-filtering or
output-filtering classes (like James Kanze's code you gave). The
classes I wrote are a general filter framework; for input, output,
miscellaneous, or a combination of these.
2. What's the deal with the "complexity"? Since there are 12 points of
stream buffer overriding (although there are related groups), I have to
put in 12 sets of filtering methods. It can't be considered complex if
there is nothing left to remove without leaving a hole.
3. I could have used just a filtering stream-buffer class, without a
separate filter class hierarchy. However, I want to limit the amount
of customization, so steps I consider important wouldn't be skipped.
Since (almost) all of the stream-buffer functionality is in its virtual
methods, which I have to change, an user can create overrides that
totally skip my changes. So I designed a stream buffer class that
users should not change, and moved the customizable parts to the filter
class hierarchy.
4. The filter class is definitely _not_ final. It is missing the
functionality overrides. The non-virtual functions, starting with
"doing_", would call the future overrides to do parts of their
functionalities. The default implementations of the future virtual
functions would make the non-virtual functions act as those non-virtual
functions currently are (i.e. pass-through). These defaults would
allow, for example, an user to add output filtering without worrying
how the input and miscellaneous methods operated.
Daryle