Hi Robert, "Stewart, Robert" <Robert.Stewart@sig.com> 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?
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.
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). However, if the adaptor were the one way to get the nice interface you're after, and it provides a means of using many different containers with various functions and classes, including your packet class, doesn't that seem cleaner overall?
I fail to see why we can't have both, seeing that they are not mutually exclusive. 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