RE: [boost] small but handy (to me) data buffer class

From: Matthew Hurd (matt_at_[hidden])
Date: 2004-03-26 07:35:13

> On Behalf Of Rob Stewart
> Subject: Re: [boost] small but handy (to me) data buffer class

Hi Rob,

Fancy meeting you here.  We work at the same company, SIG, just on different
sides of the world.  I work on the top side in Sydney and you work down
north ;-)

> 
> Isn't that the purpose of shared_ptr and shared_array?

A shared_ptr idiom works just dandy.  Trouble is you have to add all the
alternatives with a handle-like idiom, or some such, which drives you to
policies and you end up with something similar in complexity anyway but
perhaps not quite as to the point.

> The header wasn't in this message, so I can't see what problem
> you're really trying to solve.

Yup.  Was eaten by the gmane mail monster.  There have been some problems
with that as per David Abrahams MPL FSM example.  I thought it was solved
though.  I'll try again and cc you.

> > I also had a goal of the potential for binary compatibility with a =
> > struct
> > buffer { size t size; char * data; } as per WSABUF on win32, and many =
> > other
> > standardish buffers, which limited the choices a little.
> 
> Interesting.

The WSABUF compatibility should be OK with EBO as in VC7.1 and since the
policies in the code are static the policy inheritance could just be
eliminated completely getting binary compatibility for even Borland perhaps.

Being able to annotate quite clearly and simply the appropriate semantics
for data block ownership for network libs drove my turning 
        struct thing { size_t size; char * data; }
into several more lines.  Win32/64, bsd, ACE, Ensemble, etc all have varying
semantics for handling data blocks which at least with simple policies you
can approach declaratively.  At least that was the idea, not sure it is not
overkill though as it is all much ado about nothing.

// some declarations, for example

data<> usual;
data<256, create_refer, kill_delete > take_responsibility_for;
data<256, create_new, kill_delete > page6502;
data<4096, create_new, kill_delete, __int8, __int64 > vm_page;
data<MTU_SIZE, create_refer, kill_free, char*, __int64 > dodgy;
data<1e10, create_refer, kill_free, char*, __int64 > big_sucker_zero_copy;

data_standard_ptr     dont_copy___share_the_love;  // non-copyable

I've found the iterator on the buffer via the neat boost::iterator_facade is
handy syntax sugar too.  (If I did it correctly, I was a façade virgin.)

Regards,

Matt Hurd
matt_at_[hidden], hurdm_at_[hidden] or matthurd_at_[hidden]