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
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
