From 1110979364169287304 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,a503f12190fad83c X-Google-Attributes: gidf78e5,public From: Dietmar Kuehl Subject: Re: What does the standard say about file descriptors Date: 1999/10/14 Message-ID: <7u5949$2kc$1@nnrp1.deja.com>#1/1 X-Deja-AN: 536809760 X-NNTP-Posting-Host: 145.253.2.41 Approved: stephen.clamage@sun.com (comp.std.c++) References: To: lush@erc.msstate.edu X-UID: 0000000001 X-Status: $$$T X-Http-User-Agent: Mozilla/4.61 [en] (X11; I; Linux 2.2.10 i586) X-Http-Proxy: HTTP/1.0 10.14.5.129 (IBM-WTE), 1.0 x36.deja.com:80 (Squid/1.1.22) for client 145.253.2.41 Organization: Deja.com - Before you buy. X-Article-Creation-Date: Thu Oct 14 18:58:26 1999 GMT X-MyDeja-Info: XMYDJUIDdietmar_kuehl Newsgroups: comp.std.c++ Originator: clamage@taumet Hi, to start by answering the question in the subject line: The standard is silent about using file descriptors with standard streams. I haven't checked but it is likely that the standard does not mention file descriptors at all. In article , Edward Luke wrote: > I find that sometimes I need to interface iostream objects with low > level POSIX file descriptors. For example, I would like to have a > ostream that connects to a pipe via POSIX popen(). ... but 'popen()' is not related to file descriptors at all: It returns a 'FILE*'! Some implementations have an extension which allows to use a file descriptor as a constructor argument or as the argument to the 'open()' function. My implementation deliberately does not define such a constructor: If you use it, you are using stuff outside the standard and in this case you should better be aware of this fact. The approach to be taken is to use a special stream buffer, eg. called 'POSIXbuf' for obvious reasons, which can be constructed from a file descriptor and which might also add other useful functionality which is specific to the POSIX file handling, eg. locking, mmap(2)ing, access to file attributes, etc. Such a stream buffer is, of course, highly platform specific but reasonably easy to implement (I have an implementation which I want to submit to but I haven't yet decided on all the involved features...). Now to 'popen()': This is a fairly easy one. The interface to 'FILE*' is standardized and thus it is possible and actually quite easy to implement a simple stream buffer on top of 'FILE*'. Here is one for starters: class stdiobuf: public std::streambuf { public: typedef std::char_traits traits_type; typedef traits_type::int_type int_type; stdiobuf(FILE* file): m_file(file) {} protected: int_type overflow(int_type c) { if (!traits_type::eq_int_type(c, traits_type::eof())) return std::fputc(c, m_file); return c; } int_type underflow() { int_type c = std::fgetc(m_file); if (!traits_type::eq_int_Type(c, traits_type::eof())) { m_buffer = c; setg(&m_buffer, &m_buffer, &m_buffer + 1); } return c; } private: FILE* m_file; char m_buffer; }; This stuff is not tested and only intended to give an expression what is necessary to create a new stream buffer. A real implementation with support for seeking (not necessary for pipes...), buffering, etc. is somewhat more involved. Also, to enhance the performance, a real implementation might access stdio internals. Of course, this is then again not portable... > I realize that this > operation can be system specific, however I would like it to be as > portable as possible (as in portable to all POSIX systems). Do I have > to abandon streams to accomplish this, or is there a `standard' > approach or even a `suggested' approach? If you need to write to or read from a stream which is not supported by the standard C++ library, you can just create a new one. This is somewhat different to the C library where there is no way to extend the I/O mechanism. In C++ you can create various stream using very different "external representations". -- homepage: Sent via Deja.com http://www.deja.com/ Before you buy. [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]