Aaron W. LaFramboise wrote: Hi Aaron,
Simon Richter wrote:
Hrm, I have never missed being able to access files from a lower level than iostreams so far. :-) I never do binary I/O directly in my applications but always implement an inserter/extractor pair that uses streambuf iterators, though.
iostreams' read()/write() should be enough for stream-based I/O, and for datagrams I'd propose going through another step anyway (i.e. have a separate stream class that does not derive from the standard iostreams but rather allows inserting and extracting packets only.
What write()?
And as far as read(), can someone explain to me how its possible to use this interface for anything other than files? As near as I can tell, it has no way of expressing how much data it actually read, which is unacceptable, and useless, and really next door to defect-land in my opinion. readsome() returns streamsize, but this function isn't that useful either, as it will never trigger a call to underflow().
there was at least one long discussion about socket streams some time ago. If I recall correctly the discussion ended with 1) socket streams are desirable for a socket library as they provide an interface many developers are familiar with (these developers can then create simple network application quickly) and 2) socket streams can only support blocking I/O (even this could be limited though). Boris
[...]