RE: [boost] Re: sockets library

From: Darryl Green (green_at_[hidden])
Date: 2001-12-20 22:39:29

<rant>
There are LOTS OF platforms in existance that are not win32, un*x or mac and
do have BSD socket style networking.
There are environments in which using iostreams is BANNED and where using
sockets certainly isn't.
There are protocols that are not designed so humans can read them, but are
designed so the data will fit (either a lot of data, or a small pipe) and/or
be efficently processed at each end.
There are protocols that have some truly exotic and complex internal
structure that no amount of iostream handling is going to help with. Well -
ok - I guess someone could build some interesting magic for formatting data
as (say) ASN.1 via iostreams, but I'm not volunteering.
<rant/>
KISS.

Darryl Green.

> -----Original Message-----
> From: mfdylan [mailto:dylan_at_[hidden]]
> Sent: Thursday, 20 December 2001 8:53 PM
> To: boost_at_[hidden]
> Subject: [boost] Re: sockets library
> 
> 
> --- 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
> 
> 
> 
> 
> Info: http://www.boost.org  Send unsubscribe requests to: 
<mailto:boost-unsubscribe_at_[hidden]> 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/