Hi Robert, "Stewart, Robert" <Robert.Stewart@sig.com> 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. 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.
Does this make sense?
Yes, it does. We are trying to solve orthogonal problems here. I want a simple and convenient buffer abstraction that will manage the memory for me and provide a natural interface. You are trying to find a way to work with various buffer representations (of which my buffer class is just one instance) in a uniform way. You are viewing this from the library designer's point of view ("How can I design my socket class so I don't have to deal with all these different buffer representations?"). I am think from the user's point of view ("What can I use to manage the buffer memory for me and make my code succinct?"). Boris -- Boris Kolpackov, Code Synthesis http://codesynthesis.com/~boris/blog Compiler-based ORM system for C++ http://codesynthesis.com/products/odb Open-source XML data binding for C++ http://codesynthesis.com/products/xsd XML data binding for embedded systems http://codesynthesis.com/products/xsde