Boost logo

Boost :

Subject: Re: [boost] Interest in a simple buffer abstraction?
From: Boris Kolpackov (boris_at_[hidden])
Date: 2011-01-31 11:58:30

Hi Robert,

"Stewart, Robert" <Robert.Stewart_at_[hidden]> 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


Boris Kolpackov, Code Synthesis
Compiler-based ORM system for C++
Open-source XML data binding for C++
XML data binding for embedded systems

Boost list run by bdawes at, gregod at, cpdaniel at, john at