From: Daryle Walker (darylew_at_[hidden])
Date: 2001-01-23 13:13:24
on 1/22/01 12:50 PM, Joe Mariadassou at JMariadassou_at_[hidden] wrote:
> Now suppose I override only overflow and sync as before, and the client
> calls xsputn. The output will landup straight into ofstream::streambuf's
> xsputn which will in turn call its own version of overflow. So the data will
> not pass through my filter.
I didn't see a declaration for the transformation algorithm in your class's
declaration. I guess this is so because the algorithm is embedded in your
"overflow" method. You should move it to a separate (private and
non-virtual) method. Reasons:
1. Better separation of concerns. Encapsulating the algorithm lets you
tinker with it or the rest of overflowing independently of the other.
2. Some of my solutions require your algorithm to be accessible to a new
"xsputn" method. Copying & pasting the algorithm from "overflow" to
"xsputn" would be a maintenance nightmare.
Your first solution worked for multiple characters because the default
implementation of "xsputn" indirectly called your new "overflow" method. My
version calls the inner streambuf's "xsputn" instead, skipping any of your
filtering. Possible solutions:
1. Override "xsputn" to do what the original default implementation does
for ( std::streamsize i = 0 ; i < n ; ++i )
this->sputc( s[i] );
// you could use a combination of for_each and mem_fun instead
1A. Question for the C++ experts: could Joe just call std::streambuf::xsputn
directly in his override of "xsputn" to skip my override of "xsputn,"
but not his "overflow" override?
2. Override "xsputn." In it, make another copy of the array to be written.
Change the characters with your transformation method. Then call my
"xsputn" with the new array. (Make sure to destroy the array.) This
has the advantage over  in that it allows the inner streambuf's
"xsputn" to be used.
-- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT mac DOT com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk