Scott Woods wrote: Hi Scott,
[...]
If I understand correctly your socket streams support blocking I/O. However I/O methods are guaranteed to return immediately as data is copied to the so-called "application zone" where it waits until it is sent to the network?
Yes to the first question (i.e. blocking I/O).
Not clear on what you were asking in the second. I'll try the shotgun approach and hope I hit something :-)
I try again, too. :-) What I wanted to say is that the blocking I/O methods of your socket stream always return immediately. They block but don't need to wait because they just copy data to another application buffer. When the library user calls your operator<< he knows the call will return immediately and not after eg. 10 seconds. Is this correct?
[...] My approach to input is (inevitably? ;-) completely different. There are no "operator>>( stream &, application_object & )"'s to match the output operators; the design is asymmetric. This is for the simple reason that a function with such a signature implies blocking; it must wait for potentially multiple network reads to complete the application_object. The design is fully async.
If there is no operator>> don't you think you make socket streams less useful for library users? Isn't the idea of socket streams that library users who are familiar with the interface of iostreams can start sending and receiving data on the network without knowing too much about the details? If you write "std::cin >> a;" you know it will stop your program until something is entered. I'd think it makes sense if socket streams behave similarly? Boris