[boost] Re: IOStreams formal review start

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