Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk