"Thorsten Ottosen" <nesotto@cs.auc.dk> wrote in message news:ch96uf$ie9$1@sea.gmane.org...
"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.
Whenever this member is called internally by the library, the buffer is guaranteed to be big enough. Users can also call it directly; in this case it's up to them to make sure s is big enough -- just as when a user invokes std::ostream::write.
| > 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?
No, but I guess they should.
br
Thorsten
Jonathan