From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2005-08-19 09:32:28
--- Rob Stewart <stewart_at_[hidden]> wrote:
> From: Christopher Kohlhoff <chris_at_[hidden]>
> Don't construct a vector of a given size or use resize(), then.
> Rely on reserve() instead.
It's my understanding that you cannot access the address &vec[N] (or
&vec + N) unless 0 <= N < size(), and reserve() doesn't change the
size of the vector.
> OTOH, using swap(), *if* a user used a vector<double>
> instead of the array you mention, then vector won't add overhead.
But Thorsten was proposing only the use of vector<char>, so you would
still need to convert from vector<double> to vector<char>.
> Instead, how about a std::vector-like class that takes a
> user-defined, fixed-size block of memory? Then, instead of using
> an allocator, it uses its own memory management class that doles
> out elements from the fixed, user-supplied memory. Such a class
> could even avoid the default construction worry altogether by
> eliminating resize() and making the constructor that takes a
> number simply reserve that much space. (Deviating that much from
> std::vector means you wouldn't want to make it too similar, or at
> least you'd want the name to be quite dissimilar.) Using a
> user-supplied block of memory means that the memory can come from
> a stack allocation, static memory, the free store, a memory
> mapped file, etc. That class cannot be copyable, but it could be
> movable and swappable.
I'd be happy to look at a proposed interface for it, if you'd like to
sketch it out. However it would have to provide a straightforward way
of sending an existing application data structure (and it may be hard
to beat void* for that) that doesn't add time or space overhead in an
Basically I'm still of the opinion that the operations on the socket
class should deal in void* to allow for users that need to be close to
the metal. But since safe, efficient buffer management seems to be a
common need/desire, perhaps there is a place for that in asio with a
buffer class (or should it be a Buffer concept?) and non-member
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk