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-31 12:24:33

Boris Kolpackov wrote:
> "Stewart, Robert" <Robert.Stewart_at_[hidden]> writes:
>
> > 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).
>
> BTW, do you have any ideas about how such an adapter can be
> implemented that is fast (virtual functions are probably not
> an option), easy to use, and extensible?

Yes.  I've done something similar for strings, which adapts a char * plus a length, an iterator pair, a std::vector<char>, etc., all of which are presumed to refer to an empty buffer initially, and provides for the ability to append and assign (within the initial capacity), provides iterators (char const *'s), capacity and length queries, etc. from a pointer, a length, and a capacity.

To permit adaptation to other types would require defining a concept for extracting a capacity and pointer to the buffer start, such that a templated constructor can apply the appropriate concept functions to capture the needed values.

> > 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.
>
> Of course, if the library needs to return a buffer, ownership issues
> arise again.

Maybe.  It may be that the library alone knows the needed buffer size, in which case its interface could be complicated by requiring the user to ask for the size, create a buffer, and then call the function to load the buffer (which must assume or verify the size).  In that case, yes, the library might need to allocate memory and return something that manages its lifetime.  However, that could be a simple memory allocation managed by, say, boost::shared_ptr, and the caller could use the adaptor to get the desired high level interface.

There are other ways of doing such things, but you get the idea.

> > 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).
>
> I fail to see why we can't have both, seeing that they are
> not mutually exclusive.

I'm attempting to show that there may really be no need for your class.  If the adaptor approach works nicely and provides better genericity, it seems like the better direction.  You may yet find a compelling case for your idea, but given the other push back, I thought the adaptor approach might be ideal.

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