"Jonathan Turkanis" <technews@kangaroologic.com> wrote in message news:ch8b4q$4cd$1@sea.gmane.org... | | "Thorsten Ottosen" <nesotto@cs.auc.dk> wrote in message | > 2. How is boundcheking applied in this example: | > | > struct vector_sink : public sink { | > vector_sink(vector<char>& vec) : vec(vec) { } | > void write(const char* s, std::streamsize n) | > { | > vec.insert(vec.end(), s, s + n); | > } | > | > I mean, could't n be too big? | | This is supposed to extend the vector. Are you worried that n + vec.size() will | exceed std::vector::max_size()? no, I was thinking, is the buffer at 's' big enough to always hold n more elements...ie...is this guaranteed by the framework design. | > 10. In example like | > | > filtering_istream in(adapt(s.begin(), s.end())); | > filtering_istream in(s.begin(), s.end()); | > | > it seems that you could remove the iterator pair version and provide a | ForwardReadableRange version | | The problem is there's no way to distinguish at compile time between an | arbitrary use-defined filter or resource and an arbitrary ForwardReadableRange | (unless you're suggesting I do a lot of member-detection). ok, yeah, that's probably very non-portable. | > 11. What is the difference between the two examples in "III. Appending to an | STL Sequence" besides one is | > much more clumsy? | | I assume you mean the first is more clumsy. Unfortunately, it's also more | efficient. It uses a plain streambuf_facade, while the second example uses a | filtering_ostream, which delegates to a (length one) chain of streambuf_facades. | The filtering infrastructure has some overhead, so unless I'm actually going to | add filters to the chain I'd prefer the first example. ok, did the docs talk about this efficiency difference? br Thorsten