Boost logo

Boost :

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 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?)

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at