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 13:46:52

Boris Kolpackov wrote:
> "Stewart, Robert" <Robert.Stewart_at_[hidden]> writes:
>
> > Of course those are options, but then you're imposing a new
> > container on clients of packet and on other libraries.
> >
> > Consider some existing code that uses a std::vector<char>. You would
> > require that it be changed to use your buffer type.
>
> I think requiring users of your API to pass buffers as vector<char>
> only is crazy.

Crazy or not, such things are often done.

> Any existing code that tries to be universally usable
> will at least allow for the (void*, size_t) pair as the buffer
> representation which will work just fine with the buffer abstraction
> I am proposing.

That interface is more error prone.  With std::vector<char>, the memory and size are intrinsically related.  However, that's beside the point.  There's a great deal of extant code that uses various ways to allocate and pass buffers.

Your buffer class provides slightly simpler syntax than std::vector<char>, but is non-standard, so I'm not sure it will gain much traction.

Your examples of similar types in other Boost libraries suggest that something might be needed, but I suggest that those libraries should use something like my adaptor idea.  If they were changed accordingly, then the onus falls on clients of those libraries to create a suitable buffer any way that makes sense to the client (and can be or has been adapted).  If the library needs to create a buffer, the buffer can be of any type since the adaptor can be used everywhere it is referenced to provide the simpler, common interface.

Obviously, my adaptor idea and your buffer type are not mutually exclusive, but if the adaptor provided the interface you wanted, then you wouldn't need to have your buffer type but could use any number of other types as appropriate to the context.

Clearly, if you have a function or a class that creates and manipulates the buffer, then the adaptor approach is a little less direct as one would need both the container and the adaptor in the same scope (as you showed in an earlier variant of the example packet class).  However, if the adaptor were the one way to get the nice interface you're after, and it provides a means of using many different containers with various functions and classes, including your packet class, doesn't that seem cleaner overall?

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

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