Re: [boost] Interest in a simple buffer abstraction?

Subject: Re: [boost] Interest in a simple buffer abstraction?
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2011-01-27 09:51:08

Boris Kolpackov wrote:
>
> I hoped to find something that would encapsulate the memory
> management and provide basic operations like copy (memcpy),
> append, set all bytes in a buffer to a specific value
> (memset), etc. Something that I could use like this:
>
> class packet
> {
>   address to_;
>   boost::buffer payload_;
>
> public:
>   packet (const address& to, const void* data, std::size_t size)
>     to_ (to), data_ (data, size)
                ^^^^^
                payload_?

>   {
>   }
>
>   const boost::buffer& payload () const
>   {
>     return payload_;
>   }
> };
[snip]
>
> I would like to propose a simple buffer abstraction for
> inclusion into Boost. Here are some additional motivations:
>
>  - Seeing that there is a number of library-specific implementations,
>    it is quite clear that such a class is often needed.
>
>  - If we have a "top-level" buffer class, various i/o libraries could
>    use it in their interfaces which would lead to better library
>    interoperability (i.e., one could receive data from a socket into
>    a buffer using asio and then pass that buffer to iostream or
>    interprocess without any conversions).
>
>  - A top-level buffer class will be fairly light-weight (perhaps even
>    header-only). Right now, if I am to use a buffer implementation from
>    say, asio, I need to install and potentially link to that library.

The idea has merit, but I wonder if an adaptor approach would be better.  That is, permit construction of your buffer type from various other storage types, like std::vector, boost::array, char [], etc., and simply adapt them to a common interface for use by other code.

Memory management would be outside the scope of the adaptor as it exists merely to overlay an abstraction on the specific storage medium in use, but that also eliminates the issues Mathias is raising.  That restricts the API a bit from your vision, but appending, copying, iterators, etc. are still possible.

Storage lifetime must exceed that of the adaptor of course.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.