Interest in a simple buffer abstraction?

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Interest in a simple buffer abstraction?

Boris Kolpackov-2
Hi,

While working on the Boost profile for ODB C++ ORM[1], I was looking
for a Boost type to map the database BLOB type to. 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)
  {
  }

  const boost::buffer& payload () const
  {
    return payload_;
  }
};

class socket
{
public:
  void send (const packet& p)
  {
    ...
    s_.send (p.payload ().data (), p.payload ().size ())
  }
};


I found a number of buffer types in asio (asio/buffer.hpp) but they
don't do memory management. I also found auto_buffer in implementation
details of signal2 (signal2/detail/auto_buffer.hxx) and buffer in
implementation details of iostream (iostream/detail/buffer.hxx). But
they appear to be purpose-built for the libraries in question.

So, unless I missed something obvious, 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.

If the community believes this is a good idea, I will next send the
buffer interface for review/discussion.

Let me know what you think.

[1] http://www.codesynthesis.com/products/odb/

Boris

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Interest in a simple buffer abstraction?

Mathias Gaunard-2
On 27/01/2011 11:53, Boris Kolpackov wrote:

> Hi,
>
> While working on the Boost profile for ODB C++ ORM[1], I was looking
> for a Boost type to map the database BLOB type to. 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)
>    {
>    }
>
>    const boost::buffer&  payload () const
>    {
>      return payload_;
>    }
> };
>
> class socket
> {
> public:
>    void send (const packet&  p)
>    {
>      ...
>      s_.send (p.payload ().data (), p.payload ().size ())
>    }
> };

How is that any different from std::vector<char>?

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Interest in a simple buffer abstraction?

Boris Kolpackov-2
Hi Mathias,

Mathias Gaunard <[hidden email]> writes:

> How is that any different from std::vector<char>?

Ah, that's right, I forgot to cover this case. The main problem with
using vector<char> as a binary buffer is the unnatural interface.

Provided:

typedef std::vector<char> vbuffer;

Compare:

       buffer                          vbuffer
--------------------------------------------------------------------
                             |
buffer b (data, size);       | vbuffer b (data, data + size);
                             |
const char* p = b.data ();   | const char* p = &b[0];
                             |
b.copy (data, size);         | b.assign (data, data + size);
                             |
b.append (data, size);       | b.insert (b.end (), data, data + size);

Also, you cannot pass the data to vector as void* which will be possible
with the buffer class, for example:

void* data;
...
buffer b (data, size); // Ok.
vbuffer vb (data, data + size); // Error.

Plus, some natural to have functions are not available in vector, for
example:

buffer b (size, capacity);
buffer b (data, size, capacity);

Also, for a binary buffer it is nice to be able to assume ownership of
an existing raw buffer and to detach the underlying raw buffer.

Finally, the implementation of std::vector<char> may not be as efficient
(e.g., using loops to copy elements instead of memcpy, etc).

So, to summarize, yes, it is possible to use vector as a binary buffer
(and a lot of people do so), but a separate buffer class will be able
to provide a more natural interface and also some additional
functionality.

Boris
--
Boris Kolpackov, Code Synthesis        http://codesynthesis.com/~boris/blog
Compiler-based ORM system for C++      http://codesynthesis.com/products/odb
Open-source XML data binding for C++   http://codesynthesis.com/products/xsd
XML data binding for embedded systems  http://codesynthesis.com/products/xsde

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Interest in a simple buffer abstraction?

Mathias Gaunard-2
On 27/01/2011 13:37, Boris Kolpackov wrote:

> const char* p = b.data ();   | const char* p =&b[0];

That's actually undefined behaviour if b doesn't have at least 1 element.
In C++0x std::vector has a data() member just like your buffer type.


> b.copy (data, size);         | b.assign (data, data + size);

How about std::vector<char> a; std::vector<char> b = a;

>                               |
> b.append (data, size);       | b.insert (b.end (), data, data + size);

Appending is more of a string thing. Are you sure you want this?



> Also, you cannot pass the data to vector as void* which will be possible
> with the buffer class, for example:
>
> void* data;
> ...
> buffer b (data, size); // Ok.
> vbuffer vb (data, data + size); // Error.

Beware of the strict aliasing rules.


> Plus, some natural to have functions are not available in vector, for
> example:
>
> buffer b (size, capacity);
> buffer b (data, size, capacity);
>
> Also, for a binary buffer it is nice to be able to assume ownership of
> an existing raw buffer and to detach the underlying raw buffer.

And how is that allowed by your interface?
Also, how do you take care of how the memory is allocated when copying
said buffer?


> Finally, the implementation of std::vector<char>  may not be as efficient
> (e.g., using loops to copy elements instead of memcpy, etc).

std::vector can detect PODs.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Interest in a simple buffer abstraction?

Boris Kolpackov-2
Hi Mathias,

Mathias Gaunard <[hidden email]> writes:

> In C++0x std::vector has a data() member just like your buffer type.

True, thought, that's not the only problem with vector's interface
when used as buffer. Probably just the ugliest.


> > b.copy (data, size);         | b.assign (data, data + size);
>
> How about std::vector<char> a; std::vector<char> b = a;

Not sure I follow what you are trying to say here.


> > b.append (data, size);       | b.insert (b.end (), data, data + size);
>
> Appending is more of a string thing. Are you sure you want this?

I don't see why not, but I am open to change my mind if there is a
good reason not to provide it.


> > void* data;
> > ...
> > buffer b (data, size); // Ok.
> > vbuffer vb (data, data + size); // Error.
>
> Beware of the strict aliasing rules.

Seeing that we will just pass the pointer to memcpy, I think we will
be safe.


> > Also, for a binary buffer it is nice to be able to assume ownership of
> > an existing raw buffer and to detach the underlying raw buffer.
>
> And how is that allowed by your interface?

There would a special constructor for that:

buffer (char* data, size_t size, size_t capacity, bool assume_ownership);

> Also, how do you take care of how the memory is allocated when copying
> said buffer?

You probably mean "freeing said buffer" instead of "copying said buffer".
The simplest approach would be to stipulate that such a buffer should be
allocated with operator new[] and freed with operator delete[].

Boris
--
Boris Kolpackov, Code Synthesis        http://codesynthesis.com/~boris/blog
Compiler-based ORM system for C++      http://codesynthesis.com/products/odb
Open-source XML data binding for C++   http://codesynthesis.com/products/xsd
XML data binding for embedded systems  http://codesynthesis.com/products/xsde

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Interest in a simple buffer abstraction?

Stewart, Robert
In reply to this post by Mathias Gaunard-2
Mathias Gaunard wrote:
> On 27/01/2011 13:37, Boris Kolpackov wrote:
>
> > b.copy (data, size);         | b.assign (data, data + size);
>
> How about std::vector<char> a; std::vector<char> b = a;

The point was succinctness for the purpose at hand.

> > b.append (data, size);       | b.insert (b.end (), data, data + size);
>
> Appending is more of a string thing. Are you sure you want this?

Imagine reading several times from a socket to try to fill a buffer before returning.

_____
Rob Stewart                           [hidden email]
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.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Interest in a simple buffer abstraction?

Mathias Gaunard-2
In reply to this post by Boris Kolpackov-2
On 27/01/2011 15:10, Boris Kolpackov wrote:

> You probably mean "freeing said buffer" instead of "copying said buffer".
> The simplest approach would be to stipulate that such a buffer should be
> allocated with operator new[] and freed with operator delete[].

No, I did mean copy, as in when you copy the buffer object.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Interest in a simple buffer abstraction?

Mathias Gaunard-2
In reply to this post by Boris Kolpackov-2
On 27/01/2011 15:10, Boris Kolpackov wrote:

> You probably mean "freeing said buffer" instead of "copying said buffer".
> The simplest approach would be to stipulate that such a buffer should be
> allocated with operator new[] and freed with operator delete[].

Oh and calling delete[] (or delete for that matter) on a different type
than the one that was used for new[]/new (or a non-base type if the
destructor is virtual) is undefined behaviour.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Interest in a simple buffer abstraction?

Vicente Botet
In reply to this post by Boris Kolpackov-2
Boris Kolpackov-2 wrote
So, unless I missed something obvious, 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.

If the community believes this is a good idea, I will next send the
buffer interface for review/discussion.

Let me know what you think.
I'm working on a frame concept, which is something like a bidirectional buffer. It allows to prepend and append binary data, and obtain/remove the header and the trailer.

In addition we can split a frame in fragments and join fragments to make a frame.

All these features are needed when working with protocol stacks.

Best,
Vicente

Reply | Threaded
Open this post in threaded view
|

Re: Interest in a simple buffer abstraction?

Stewart, Robert
In reply to this post by Boris Kolpackov-2
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                           [hidden email]
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.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Interest in a simple buffer abstraction?

Dean Michael Berris
In reply to this post by Vicente Botet
On Thu, Jan 27, 2011 at 10:49 PM, Vicente Botet
<[hidden email]> wrote:

>
> I'm working on a frame concept, which is something like a bidirectional
> buffer. It allows to prepend and append binary data, and obtain/remove the
> header and the trailer.
>
> In addition we can split a frame in fragments and join fragments to make a
> frame.
>
> All these features are needed when working with protocol stacks.
>

+1

Something like this is very welcome indeed.

--
Dean Michael Berris
about.me/deanberris
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Interest in a simple buffer abstraction?

Cory Nelson
In reply to this post by Vicente Botet
On Thu, Jan 27, 2011 at 6:49 AM, Vicente Botet <[hidden email]> wrote:

> I'm working on a frame concept, which is something like a bidirectional
> buffer. It allows to prepend and append binary data, and obtain/remove the
> header and the trailer.
>
> In addition we can split a frame in fragments and join fragments to make a
> frame.
>
> All these features are needed when working with protocol stacks.
>
> Best,
> Vicente
>

You'll have a winner if you expand that to allow bidirectional
iteration of both bytes and fragments (and then a fragment is just a
raw array giving random-access iteration within them).  VERY useful
for high-performance incremental parsing, I would definitely give my
+1 for boost inclusion.

--
Cory Nelson
http://int64.org
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Interest in a simple buffer abstraction?

Christian Holmquist
In reply to this post by Stewart, Robert
> >  - 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.
>
>
> You don't need to link to asio to use its buffer API. If you can use all
other Boost header only libs, you can use asio as well.
Personally, I like the approach taken by asio, I wished it were used in more
places (Boost,interprocess comes to mind).
What's missing in asio's buffer interface that you would like to add?
Inventing another unmanaged buffer abstraction seems not the right way to go
IMO.

- christian
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Interest in a simple buffer abstraction?

Boris Kolpackov-2
In reply to this post by Mathias Gaunard-2
Hi Mathias,

Mathias Gaunard <[hidden email]> writes:

> No, I did mean copy, as in when you copy the buffer object.

In this case I don't see a problem. The buffer class will provide
the "deep copy" semantics, just like std::vector.

Boris
--
Boris Kolpackov, Code Synthesis        http://codesynthesis.com/~boris/blog
Compiler-based ORM system for C++      http://codesynthesis.com/products/odb
Open-source XML data binding for C++   http://codesynthesis.com/products/xsd
XML data binding for embedded systems  http://codesynthesis.com/products/xsde

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Interest in a simple buffer abstraction?

Boris Kolpackov-2
In reply to this post by Vicente Botet
Hi Vicente,

Vicente Botet <[hidden email]> writes:

> I'm working on a frame concept, which is something like a bidirectional
> buffer. It allows to prepend and append binary data, and obtain/remove the
> header and the trailer.
>
> In addition we can split a frame in fragments and join fragments to make a
> frame.

That sounds like a multi-block buffer, i.e., a buffer that instead of
one contiguous memory block manages a sequence of such blocks. While
this would allow more efficient resizing, prepending, etc., the
interface becomes somewhat more complicated. But it can be another
implementation, in addition to the simple buffer.

I didn't want to mention this possibility initially in order to keep
things simple, but it seem people here are more interested in the
complex than simple ;-).

Boris
--
Boris Kolpackov, Code Synthesis        http://codesynthesis.com/~boris/blog
Compiler-based ORM system for C++      http://codesynthesis.com/products/odb
Open-source XML data binding for C++   http://codesynthesis.com/products/xsd
XML data binding for embedded systems  http://codesynthesis.com/products/xsde

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Interest in a simple buffer abstraction?

Boris Kolpackov-2
In reply to this post by Stewart, Robert
Hi Robert,

"Stewart, Robert" <[hidden email]> writes:

> 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.

This way I would have to write:

class packet
{
  packet (void* data, size_t size)
    : data_ (data_storage_, data, size)
  {
  }

  std::vector data_storage_;
  boost::buffer data_;
};

Which i find quite hairy.

Boris
--
Boris Kolpackov, Code Synthesis        http://codesynthesis.com/~boris/blog
Compiler-based ORM system for C++      http://codesynthesis.com/products/odb
Open-source XML data binding for C++   http://codesynthesis.com/products/xsd
XML data binding for embedded systems  http://codesynthesis.com/products/xsde

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Interest in a simple buffer abstraction?

Stewart, Robert
Boris Kolpackov wrote:

> "Stewart, Robert" <[hidden email]> writes:
>
> > The idea has merit, but I wonder if an adaptor approach
> > would be better.
>
> This way I would have to write:
>
> class packet
> {
>   packet (void* data, size_t size)
>     : data_ (data_storage_, data, size)
>   {
>   }
>
>   std::vector data_storage_;

std::vector<char>, I presume.

>   boost::buffer data_;

Why would you have both?

> };

You either have this:

packet::packet(void const * _data, size_t _size)
   : data_storage_(static_cast<char const *>(_data),
        static_cast<char const *>(_data) + _size)
{
}

which means that the data is copied into data_storage_, or you have this:

packet::packet(boost::buffer & _buffer)
   : data_(_buffer)
{
}

which requires that some other code create a std::vector<char> or other container for the packet to use.  This, like any type erasing mechanism, isolates packet from the actual storage type.  The client can create a std::vector<char>, allocate an array of char on the stack, etc., and packet will work with them all.

_____
Rob Stewart                           [hidden email]
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.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Interest in a simple buffer abstraction?

Boris Kolpackov-2
Hi Robert,

"Stewart, Robert" <[hidden email]> writes:

> >   std::vector<char> data_store_;
> >   boost::buffer data_;
>
> Why would you have both?

Because I want the packet to own the data and to be able to access
it using a natural interface. With your approach I would have to
write gratuitous code like this.


> which requires that some other code create a std::vector<char> or
> other container for the packet to use.

This goes down the slippery slop of someone else owning the memory
and making sure it is not gone while other objects still reference
it. If that's the functionality you want, then why bother with the
buffer class at all? Simply store a pair: const void*, size_t; it
will be just as convenient.

Boris
--
Boris Kolpackov, Code Synthesis        http://codesynthesis.com/~boris/blog
Compiler-based ORM system for C++      http://codesynthesis.com/products/odb
Open-source XML data binding for C++   http://codesynthesis.com/products/xsd
XML data binding for embedded systems  http://codesynthesis.com/products/xsde

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Interest in a simple buffer abstraction?

Boris Kolpackov-2
In reply to this post by Christian Holmquist
Hi Christian,

Christian Holmquist <[hidden email]> writes:

> What's missing in asio's buffer interface that you would like to add?

Memory management and common functions such as copy, append, etc. Asio
buffers are just wrappers for the void*, size_t pair.

Boris
--
Boris Kolpackov, Code Synthesis        http://codesynthesis.com/~boris/blog
Compiler-based ORM system for C++      http://codesynthesis.com/products/odb
Open-source XML data binding for C++   http://codesynthesis.com/products/xsd
XML data binding for embedded systems  http://codesynthesis.com/products/xsde

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Interest in a simple buffer abstraction?

Stewart, Robert
In reply to this post by Boris Kolpackov-2
Boris Kolpackov wrote:

> "Stewart, Robert" <[hidden email]> writes:
>
> > >   std::vector<char> data_store_;
> > >   boost::buffer data_;
> >
> > Why would you have both?
>
> Because I want the packet to own the data and to be able to access
> it using a natural interface. With your approach I would have to
> write gratuitous code like this.

No you wouldn't.  As I showed in the portion of my reply that you cut, if your packet owns its data, then it would have a container of that data.  The point of my idea is that you can create a packet type that *doesn't* own the data or even know how the data is stored because the adaptor would abstract the underlying storage type and provide a useful interface permitting the packet to append, copy, etc.

I understand that your idea is for a type that owns the data.  I'm proposing an alternative view of the problem.

> > which requires that some other code create a std::vector<char> or
> > other container for the packet to use.
>
> This goes down the slippery slop of someone else owning the memory
> and making sure it is not gone while other objects still reference
> it.

When you want performance, you don't want to copy data.  Your model requires that the data be copied.  Mine references data allocated elsewhere.  As I noted, that does indeed mean that the reference mustn't outlive the allocation, but with that responsibility comes improved performance and greater flexibility.

> If that's the functionality you want, then why bother with the
> buffer class at all? Simply store a pair: const void*, size_t; it
> will be just as convenient.

As I noted (in what you snipped), the adaptor type can still provide the additional functionality you had proposed: appending, copying, etc.  You get none of that with such a pair.

When sharing a buffer among libraries, using my suggestion, memory need only be allocated in one place whilst various functions from different libraries can all reference that memory using a type-erased, feature rich, standardized reference to it.

_____
Rob Stewart                           [hidden email]
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.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
12