Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Ian Collins Newsgroups: comp.lang.c++ Subject: Re: Create an istream from an fd? Date: Sun, 28 Aug 2011 16:04:16 +1200 Lines: 52 Message-ID: <9btt20FopsU7@mid.individual.net> References: <27743f07-a009-4f80-aa2f-5ab9dd9fdd9a@19g2000vbv.googlegroups.com> <9bqok6FeijU2@mid.individual.net> <9btaq6FopsU5@mid.individual.net> <2be71f2e-9a18-42ab-a7ec-bc7f8ccb215e@i9g2000yqk.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net XZauXXcp+wrUJ5OH3VOdyQsakOJNYOjpmfMcup+9rbuD7elNRD Cancel-Lock: sha1:ggQtxH8lcXWTPKqlEJjwpGsqWoI= User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.9) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.4 In-Reply-To: <2be71f2e-9a18-42ab-a7ec-bc7f8ccb215e@i9g2000yqk.googlegroups.com> Xref: x330-a1.tempe.blueboxinc.net comp.lang.c++:9389 On 08/28/11 11:35 AM, James Kanze wrote: > On Aug 27, 11:52 pm, Ian Collins wrote: >> On 08/27/11 12:46 PM, Alf P. Steinbach wrote: > >>> On 27.08.2011 01:30, Ian Collins wrote: >>>> On 08/27/11 11:26 AM, Alf P. Steinbach wrote: >>>>> On 26.08.2011 17:54, Noah Roberts wrote: >>>>>> Is there a straight forward of creating an istream out of a file >>>>>> descriptor? If there is I'd like to use it before going off and >>>>>> making such a thing. > >>>>> Compiler-specific. > >>>> Compiler, or platform? > >>> Well, to be precise, it's specific to the standard library >>> implementation. But usually one does not replace the one bundled with >>> the compiler. So then it's compiler-specific. > >> How so? There aren't any istream constructors or other members that >> work with file descriptors. I guess there could be library extensions, >> but they are part of the "standard" library, are they? > >> My point was the notion of a "file descriptor" is platform specific, so >> any streambuf derivative that uses one would also be platform specific. > > It's largely a quality of implementation issue. As you say, > there is no portable "file descriptor" type, so the standard > doesn't provide a constructor for filebuf which takes one. The > implementor is left with three choices: > > -- add the necessary constructor, as an extention (provided > that this doesn't cause ambiguities with an existing > constructor), > > -- offer an additional stream type whose streambuf can be > constructed from a file descriptor, or > > -- just ignore the issue. > > From a QoI point of view, the first is preferrable, the second > is fairly acceptable, and the last is very bad. From a QoI > point of view: all are fine according to the standard. The compilers I use do the first approach, but do it in subtly different ways (such as who is responsible for closing the file?). So I always use my own streambuf class. A specialised streambuf has the further advantage of easy customisation for file like entities that aren't regular files. -- Ian Collins