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(). Now, what exactly do iostreams offer to general socket work? Most socket protocol are defined in terms that have no correlation with C++ locales and whitespace-skipping rules. In other words, the iostreams concept of >> and << really isn't appropriate for sockets, even for 'text protocols,' because generally additional control will be needed. Besides this, iostreams has many annoying characteristics that are unacceptable for use in many robust sockets situations, such as reading an indeterminant amount of characters, and then just throwing them away if something goes wrong. In other words, I'd suggest we forget about iostreams. Design a good socket based on past experience that handles diverse networking situations elegantly, and let some other library like Boost.Iostreams map that to a streambuf, should <iostream> support be needed. Aaron W. LaFramboise