"Jonathan David Turkanis" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
> > 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. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost