[boost] Re: Revised streambuf library

From: Maxim Egorushkin (e-maxim_at_[hidden])
Date: 2003-07-15 12:45:54

"Jonathan David Turkanis" <technews_at_[hidden]> wrote in message
news:3F134D67.9020202_at_kangaroologic.com...

>  > 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.

Sorry, it was not obvious for me.

>  > 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.

I agree. This is just a matter of taste. I would prefer to write more
generic adapter classes and a bunch of factories.