pedro.lamarao@mndfck.org wrote:
Exposing a "socket" class is a requirement only if the proposed library wants to try to interface with old, "hybrid" code, provide the possibility for some kind of "extension" I really can't think of. A C++-only library could just not have a "socket" class, or consider it "private", and expose as the most basic thing the stream buffer. If you don't need the buffering itself, call pubsetbuf(0, 0).
I agree that streambuf is the right buffer concept for TCP sockets. I have used a 'sockstreambuf' class in the past that allows both, the data to be managed by a streambuf, as well as plug in socket- specific APIs such as all the BSD socket API. It has worked quite well, for example it allowed me to create a temporary std::istream on top of it to read out data in a 'input available' callback. FWIW, Stefan