C++ Streams and the underlying file descriptor

[Dietmar Kuehl]

Hi,
At 04:28 AM 1/17/00 -0500, Kevin Atkinson wrote:
>But WHY should I have to you a DIFFERENT stream buffer when the
>current implementation basically has to be implemented on top of file
>descriptors?

For one it is reasonable to implement it slightly different for most
applications in the first place, namely specific for character type 'char'
not using code conversion. Also, it is likely that you want more
functionality than just access to the file descriptor. For example, you
mentioned locking. Another one might be use of memory mapping or
methods to access file, terminal, etc. properties.

How this is implemented is still open. One implementation option is to
use 'basic_filebuf' as a base class (in this case character conversion
would be included) and just add the POSIX features to the derived
class, accessing the protected file descriptor in 'basic_filebuf'. This
would use the same implementation. The drawback of this approach
is that you cannot simply take the POSIX stream and use it on another
system which happens to use a different standard library implementation,
eg. the one from SGI, Dinkumware, or mine. Thus, going to a non-libstdc++
is only possible if you are either using a standard interface which is not
yet defined for POSIX or have a separat implementation. Depending on
what you concerns with a different implementations are, it might be
reasonable to have two POSIX stream implementations, one extending
the libstdc++ 'basic_filebuf' and one using only the standard C++
interface. This would basically be reasonable if code size is your major
concern. If your concern is support, I think having only one POSIX
stream is the way to go...

Regards,
  dk