Boost logo

Boost :

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2004-09-03 03:00:41


"Thorsten Ottosen" <nesotto_at_[hidden]> wrote in message
news:ch96uf$ie9$1_at_sea.gmane.org...
> "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.

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


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