Re: sockets library

From: mfdylan (dylan_at_[hidden])
Date: 2001-12-20 05:53:00

--- In boost_at_y..., Ross Smith <r-smith_at_i...> wrote:
> mfdylan wrote:
> > 
> > --- In boost_at_y..., Ross Smith <r-smith_at_i...> wrote:
> > >
> > > I'm convinced that iostreams should be reserved strictly for 
human
> > > readable text I/O, and not used for computer-to-computer
> > communication,
> > > such as sockets.
> > >
> > Well, er, most (if not all) common internet protocols are in fact
> > human readable.  For a start they are easy to debug, and work
> > regardless of byte-ordering or floating point storage mechanisms.
> > In fact unless efficiency (in space or time) is a problem, ascii
> 
> In library design (as opposed to application design), efficiency is
> _always_ a problem. ("You can build a safe library on top of an
> efficient one, but not the other way around." -- James Kanze.) If 
you
> don't give it priority in library design, you're narrowing your user
> base to a subset of potential users.

I agree entirely, but I don't think it's applicable to such a great 
degree in this case: when dealing with socket I/O, almost any CPU 
usage in your application processing input/output format is 
overwhelmed by network overhead (even to localhost, at least 
certainly under NT - unices tend to be a little more efficient).  
Obviously with socket I/O quantity of data is more of an issue, and 
if the binary representation of your data is significantly smaller 
than the ascii representation (not always the case) then you might 
have a good argument for sticking with binary.
The binary_stream class I wrote coupled with a streambuf derived 
socketbuf compiles to quite acceptably terse code (at least using 
VC), and is not noticeably slower than anything I could hand code (by 
noticeably I mean physically timing how long it takes to transit a 
few million objects across a loopback connection).  The same is true 
when used with a filebuf (providing you wait for the file to be 
flushed to disk).

Dylan