|
Boost : |
Subject: Re: [boost] Interest in a simple buffer abstraction?
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2011-01-28 10:33:02
Boris Kolpackov wrote:
> "Stewart, Robert" <Robert.Stewart_at_[hidden]> writes:
>
> > 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.
>
> Yes, which would involve having a data member of the std::vector<char>
> type. Let me put it this way: if I want *both* to own the data and
> have a convenient interface for it, I would have to have two members,
> as I showed in my original code. Is that not so?
No. If that remains the problem you wish to solve -- and I'm trying to suggest an alternative, obviously -- then you would use something like your original proposal if you really dislike std::vector<char> or other alternatives.
> > When you want performance, you don't want to copy data. Your model
> > requires that the data be copied.
>
> If you want unsafe sharing semantics, you can always pass/store
> references to the buffer instead of making a copy. For example:
>
> class packet
> {
> packet (const buffer& p): payload_ (p) {}
> buffer& payload_;
> };
>
> You also have the option of safe sharing with something like
> shared_ptr.
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. Suppose that there were other APIs that code calls expect a std::vector<char>. Code that uses your packet type and those other APIs would be forced to copy the data.
With my adaptor suggestion, packet can use the adaptor type, the client can still create a std::vector<char>, use your packet type, and still use the other APIs.
Extend that to other ways one can allocate a buffer. Suppose there's code that uses some API that allocates a buffer which it reclaims later, but exposes for client code to access. That buffer could also be adapted for use with packet, again without need to copy the data to a new data structure.
Does this make sense?
_____
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk