[boost] Re: filtered/decorated streambufs

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