From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2004-09-03 02:36:36
"Jonathan Turkanis" <technews_at_[hidden]> wrote in message news:ch8b4q$4cd$1_at_sea.gmane.org...
|
| "Thorsten Ottosen" <nesotto_at_[hidden]> 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