From: Jonathan David Turkanis (technews_at_[hidden])
Date: 2003-07-14 19:40:07
"Maxim Egorushkin" <e-maxim_at_[hidden]> wrote in message
news:<bev0ck$h6g$2_at_[hidden]>...
> I don't get the idea of reinventing the stream classes. One can use their
> rdbuf() member function to change the buffer. Could you please elaborate
on
> that?
True, the stream classes are thin wrappers. You don't have to use them if
you don't wan't to.
> You have read/write member functions of your source/sink/filter concepts
> virtual. If one went for efficiency she would stay away from virtual
> functions. With such a design you leave a user no choice.
Source/sink/filter classes don't have to derive from the basic
implementations which use virtual functions. The adapters which call the
source/sink/filters know the fully-derived types of the source/sink/filters
and shouldn't have to use virtual function dispatch. There does seem to be a
need for one non-inlinable function at each junction, if non-trivial
filtering is taking place. I address this in the efiiciency section.
> There are too many adapters, IMHO. It obscures. Since each STL sequence
> support iterators why don't use it? Generally speaking, there should be
only
> two adapters (input and output) that take any STL sequence represented by
> begin/end iterators.
The factory functions address this. You just call new_source or new_sink
with whatever object you want to make into a source/sink. This is less
verbose than using, e.g., streambuf iterators. Also, in the case of strings,
the factories return adapters which are better than generic container
adapters; with SFINAE you should be able to pass a string literal to
new_source.
Examples:
new_source<char>(v); // simpler than using
// iterator_source< vector<char>::iterator
>(v.begin(), v.end())
new_sink<char>(sb); // simpler than using
// iterator_source< ostreambu_iterator<char> >
// ( ostreambuf_iterator<char>(sb),
streambuf_iterator<char>() );
new_source<char>("hello"); // simpler than string h("hello");
// iterator_source(h.begin(), h.end()).
...
> P.S. There is a very good article by Alexandre Duret-Lutz and Thierry
Geraud
> "
> Improving Object-Oriented Generic Programming".
I'll look at it. Thanks.