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@finray.net, hurdm@sig.com or matthurd@acm.org