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-28 09:24:39

Boris Kolpackov wrote:
> "Stewart, Robert" <Robert.Stewart_at_[hidden]> 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                           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.