Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #9345 > unrolled thread

Create an istream from an fd?

Back to article view | Back to comp.lang.c++

Contents

  Create an istream from an fd? Noah Roberts <roberts.noah@gmail.com> - 2011-08-26 08:54 -0700
    Re: Create an istream from an fd? Leigh Johnston <leigh@i42.co.uk> - 2011-08-26 17:05 +0100
    Re: Create an istream from an fd? Victor Bazarov <v.bazarov@comcast.invalid> - 2011-08-26 12:20 -0400
    Re: Create an istream from an fd? Vaclav Zeman <vzeman79@sh.cvut.cz> - 2011-08-26 18:34 +0200
    Re: Create an istream from an fd? Ian Collins <ian-news@hotmail.com> - 2011-08-27 08:48 +1200
    Re: Create an istream from an fd? "Alf P. Steinbach" <alf.p.steinbach:usenet@gmail.com> - 2011-08-27 01:26 +0200
      Re: Create an istream from an fd? Ian Collins <ian-news@hotmail.com> - 2011-08-27 11:30 +1200
        Re: Create an istream from an fd? "Alf P. Steinbach" <alf.p.steinbach:usenet@gmail.com> - 2011-08-27 02:46 +0200
          Re: Create an istream from an fd? Ian Collins <ian-news@hotmail.com> - 2011-08-28 10:52 +1200
            Re: Create an istream from an fd? James Kanze <james.kanze@gmail.com> - 2011-08-27 16:35 -0700
              Re: Create an istream from an fd? Nobody <nobody@nowhere.com> - 2011-08-28 04:31 +0100
                Re: Create an istream from an fd? Ian Collins <ian-news@hotmail.com> - 2011-08-28 15:56 +1200
                  Re: Create an istream from an fd? Nobody <nobody@nowhere.com> - 2011-08-28 20:03 +0100
                    Re: Create an istream from an fd? Ian Collins <ian-news@hotmail.com> - 2011-08-29 07:52 +1200
                Re: Create an istream from an fd? James Kanze <james.kanze@gmail.com> - 2011-08-29 03:54 -0700
                  Re: Create an istream from an fd? Leigh Johnston <leigh@i42.co.uk> - 2011-08-29 13:55 +0100
                  Re: Create an istream from an fd? Nobody <nobody@nowhere.com> - 2011-08-29 20:12 +0100
                    Re: Create an istream from an fd? Ian Collins <ian-news@hotmail.com> - 2011-08-30 07:49 +1200
                      Re: Create an istream from an fd? Nobody <nobody@nowhere.com> - 2011-08-30 04:40 +0100
                        Re: Create an istream from an fd? Ian Collins <ian-news@hotmail.com> - 2011-08-30 15:51 +1200
                          Re: Create an istream from an fd? Nobody <nobody@nowhere.com> - 2011-08-31 00:03 +0100
                            Re: Create an istream from an fd? Ian Collins <ian-news@hotmail.com> - 2011-08-31 11:55 +1200
                              Re: Create an istream from an fd? Nobody <nobody@nowhere.com> - 2011-09-02 00:50 +0100
              Re: Create an istream from an fd? Ian Collins <ian-news@hotmail.com> - 2011-08-28 16:04 +1200
    Re: Create an istream from an fd? Nobody <nobody@nowhere.com> - 2011-08-27 02:40 +0100

Page 1 of 2  [1] 2  Next page →

#9345 — Create an istream from an fd?

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.

[toc] | [next] | [standalone]

#9347

On 26/08/2011 16:54, Noah Roberts wrote:
> Is there a straight forward of creating an istream out of a file
> descriptor?

No.

If there is I'd like to use it before going off and
> making such a thing.

Good luck.

/Leigh

[toc] | [prev] | [next] | [standalone]

#9349

On 8/26/2011 11:54 AM, 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.

No, there is no such a thing.  Good luck making it.

V
-- 
I do not respond to top-posted replies, please don't ask

[toc] | [prev] | [next] | [standalone]

#9350

Noah Roberts wrote, On 26.8.2011 17:54:
> 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.
Some standard libraries have extensions that give you istream out of a file
handle of some kind.

If your standard library does not have one, you can use Boost.IOStreams ([1])
library to make one (fairly) quickly.

[1] http://www.boost.org/doc/libs/1_47_0/libs/iostreams/doc/index.html

[toc] | [prev] | [next] | [standalone]

#9351

On 08/27/11 03:54 AM, 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.

As other have said, no.  But is is a reasonably trivial exercise to 
derive your own streambuf (don't try an iostream!) class from 
std::streambuf.  It also happens to be one of my favourite exercises 
when teaching C++.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#9353

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.

[toc] | [prev] | [next] | [standalone]

#9355

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?

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#9356

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.

Cheers,

- Alf

[toc] | [prev] | [next] | [standalone]

#9379

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.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#9383

On Aug 27, 11:52 pm, Ian Collins <ian-n...@hotmail.com> 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 standard could have required an implementation defined
typedef for the file descriptor in filebuf, and a constructor
for that, but as far as I know, no one proposed such a thing.)

--
James Kanze

[toc] | [prev] | [next] | [standalone]

#9387

On Sat, 27 Aug 2011 16:35:12 -0700, James Kanze wrote:

> (The standard could have required an implementation defined
> typedef for the file descriptor in filebuf, and a constructor
> for that, but as far as I know, no one proposed such a thing.)

It could have required a version of filebuf::open() (or similar) taking
a FILE*, given that <cstdio> is part of the standard. 

And, realistically, most of the machinery is likely to be in place in
order to implement cin/cout/cerr/clog. Given the existence of
ios::sync_with_stdio(), it seems like it would be quite hard to implement
this in a way that didn't facilitate creating some kind of streambuf from
a FILE*.

[toc] | [prev] | [next] | [standalone]

#9388

On 08/28/11 03:31 PM, Nobody wrote:
> On Sat, 27 Aug 2011 16:35:12 -0700, James Kanze wrote:
>
>> (The standard could have required an implementation defined
>> typedef for the file descriptor in filebuf, and a constructor
>> for that, but as far as I know, no one proposed such a thing.)
>
> It could have required a version of filebuf::open() (or similar) taking
> a FILE*, given that<cstdio>  is part of the standard.

Then you would end up with two layers of buffering and considering the 
similarity between C's fopen and constructing an fstream,  gain very little.

It also wouldn't solve one of the most common (at least for me) 
requirements: a stream over an existing file descriptor that isn't a 
regular file.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#9411

On Sun, 28 Aug 2011 15:56:58 +1200, Ian Collins wrote:

>>> (The standard could have required an implementation defined
>>> typedef for the file descriptor in filebuf, and a constructor
>>> for that, but as far as I know, no one proposed such a thing.)
>>
>> It could have required a version of filebuf::open() (or similar) taking
>> a FILE*, given that<cstdio>  is part of the standard.
> 
> Then you would end up with two layers of buffering

I see no reason why you would need two layers of buffering. The streambuf
can rely upon the stdio layer's buffering; it doesn't have to provide its
own.

> and considering the similarity between C's fopen and constructing an
> fstream,  gain very little.

fopen() and freopen() are typically not the only way to get a FILE*, even
if they're the only mechanisms specified by the standard.

It's one thing to only specify the most portable mechanisms for creating a
stdio stream, but another thing to assume that no other mechanisms exist,
effectively treating stdio as a hermetically-sealed unit which isn't to be
extended.

As it stands, any implementation wishing to extend the mechanisms for
creating streams has to do so twice: once for cstdio, once for ios.

> It also wouldn't solve one of the most common (at least for me) 
> requirements: a stream over an existing file descriptor that isn't a 
> regular file.

fdopen() doesn't care whether the descriptor refers to a regular file.
fdopen() isn't portable, but then neither are descriptors.

And whatever's there for stdin (etc) and cin (etc) already has to deal
with whatever the standard descriptors are associated with, whether a
file, tty, pipe, socket, etc.

[toc] | [prev] | [next] | [standalone]

#9414

On 08/29/11 07:03 AM, Nobody wrote:
> On Sun, 28 Aug 2011 15:56:58 +1200, Ian Collins wrote:
>
>>>> (The standard could have required an implementation defined
>>>> typedef for the file descriptor in filebuf, and a constructor
>>>> for that, but as far as I know, no one proposed such a thing.)
>>>
>>> It could have required a version of filebuf::open() (or similar) taking
>>> a FILE*, given that<cstdio>   is part of the standard.
>>
>> Then you would end up with two layers of buffering
>
> I see no reason why you would need two layers of buffering. The streambuf
> can rely upon the stdio layer's buffering; it doesn't have to provide its
> own.

Yet more kludgery.

>> and considering the similarity between C's fopen and constructing an
>> fstream,  gain very little.
>
> fopen() and freopen() are typically not the only way to get a FILE*, even
> if they're the only mechanisms specified by the standard.

They also can't be used for things like sockets, pipes and doors.

> It's one thing to only specify the most portable mechanisms for creating a
> stdio stream, but another thing to assume that no other mechanisms exist,
> effectively treating stdio as a hermetically-sealed unit which isn't to be
> extended.
>
> As it stands, any implementation wishing to extend the mechanisms for
> creating streams has to do so twice: once for cstdio, once for ios.

Why?  In C they'd extend stdio, in C++ they can use streambufs.

>> It also wouldn't solve one of the most common (at least for me)
>> requirements: a stream over an existing file descriptor that isn't a
>> regular file.
>
> fdopen() doesn't care whether the descriptor refers to a regular file.
> fdopen() isn't portable, but then neither are descriptors.

So? fopen() can't be used for to open them either.

> And whatever's there for stdin (etc) and cin (etc) already has to deal
> with whatever the standard descriptors are associated with, whether a
> file, tty, pipe, socket, etc.

Which isn't exposed to the user.  Unless the user can create a FILE* 
from one of those, the internal mechanism isn't much use.

C++ already provides the mechanism to extend std::streambuf (the 
appropriate virtual members) and using it it trivial.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#9430

On Aug 28, 4:31 am, Nobody <nob...@nowhere.com> wrote:
> On Sat, 27 Aug 2011 16:35:12 -0700, James Kanze wrote:
> > (The standard could have required an implementation defined
> > typedef for the file descriptor in filebuf, and a constructor
> > for that, but as far as I know, no one proposed such a thing.)

> It could have required a version of filebuf::open() (or similar) taking
> a FILE*, given that <cstdio> is part of the standard.

That's probably not a good idea.  It would force the
implementation of filebuf to be based on FILE*, which is not a
good thing.

> And, realistically, most of the machinery is likely to be in
> place in order to implement cin/cout/cerr/clog. Given the
> existence of ios::sync_with_stdio(), it seems like it would be
> quite hard to implement this in a way that didn't facilitate
> creating some kind of streambuf from a FILE*.

Not really.  All sync_with_stdio means is that you have to call
fflush() before each output.

--
James Kanze

[toc] | [prev] | [next] | [standalone]

#9436

On 29/08/2011 11:54, James Kanze wrote:
> On Aug 28, 4:31 am, Nobody<nob...@nowhere.com>  wrote:
>> On Sat, 27 Aug 2011 16:35:12 -0700, James Kanze wrote:
>>> (The standard could have required an implementation defined
>>> typedef for the file descriptor in filebuf, and a constructor
>>> for that, but as far as I know, no one proposed such a thing.)
>
>> It could have required a version of filebuf::open() (or similar) taking
>> a FILE*, given that<cstdio>  is part of the standard.
>
> That's probably not a good idea.  It would force the
> implementation of filebuf to be based on FILE*, which is not a
> good thing.

Nonsense.

/Leigh

[toc] | [prev] | [next] | [standalone]

#9442

On Mon, 29 Aug 2011 03:54:01 -0700, James Kanze wrote:

>> It could have required a version of filebuf::open() (or similar) taking
>> a FILE*, given that <cstdio> is part of the standard.
> 
> That's probably not a good idea.  It would force the
> implementation of filebuf to be based on FILE*, which is not a
> good thing.

That's why I added " (or similar) ". There has to be some form of
streambuf (which may or may not be filebuf) which is used for cin etc.

>> And, realistically, most of the machinery is likely to be in
>> place in order to implement cin/cout/cerr/clog. Given the
>> existence of ios::sync_with_stdio(), it seems like it would be
>> quite hard to implement this in a way that didn't facilitate
>> creating some kind of streambuf from a FILE*.
> 
> Not really.  All sync_with_stdio means is that you have to call
> fflush() before each output.

Which would mean that cout etc have to be able to get a FILE* to pass to
fflush().

But my point remains that you'd have to go out of your way to implement
cin etc in such a way that providing a way to create a streambuf from an
arbitrary FILE* would be significant extra work.

Sure, the programmer can implement something themselves. But given how
many programs will end up needing this (how many C++ programs use
third-party libraries which use FILE*?), it seems like an oversight.

[toc] | [prev] | [next] | [standalone]

#9444

On 08/30/11 07:12 AM, Nobody wrote:
> On Mon, 29 Aug 2011 03:54:01 -0700, James Kanze wrote:
>
>>> And, realistically, most of the machinery is likely to be in
>>> place in order to implement cin/cout/cerr/clog. Given the
>>> existence of ios::sync_with_stdio(), it seems like it would be
>>> quite hard to implement this in a way that didn't facilitate
>>> creating some kind of streambuf from a FILE*.
>>
>> Not really.  All sync_with_stdio means is that you have to call
>> fflush() before each output.
>
> Which would mean that cout etc have to be able to get a FILE* to pass to
> fflush().
>
> But my point remains that you'd have to go out of your way to implement
> cin etc in such a way that providing a way to create a streambuf from an
> arbitrary FILE* would be significant extra work.
>
> Sure, the programmer can implement something themselves. But given how
> many programs will end up needing this (how many C++ programs use
> third-party libraries which use FILE*?), it seems like an oversight.

A lot less than those that use a file descriptor.  Certainly in the Unix 
world, FILE* is seldom used and integer file descriptors are pretty much 
universal.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#9458

On Tue, 30 Aug 2011 07:49:06 +1200, Ian Collins wrote:

>> Sure, the programmer can implement something themselves. But given how
>> many programs will end up needing this (how many C++ programs use
>> third-party libraries which use FILE*?), it seems like an oversight.
> 
> A lot less than those that use a file descriptor.  Certainly in the Unix 
> world, FILE* is seldom used and integer file descriptors are pretty much 
> universal.

That isn't my experience. Both are common enough that I couldn't say which
of the two is the more popular. Descriptors tend to be used where
buffering is likely to get in the way (e.g. binary I/O), FILE* where
it's likely to be useful (e.g. text I/O). System calls use descriptors.
Libraries which aim to be cross-platform tend to use FILE*.

An odd case is that popen() uses FILE*; possibly because programs are more
likely to read/write text than binary via stdin/stdout, and that's easier
to do with buffered streams.

Ultimately, it doesn't make a great deal of difference, given the
availability of fdopen() and fileno(). One exception is that some
platforms support "user" streams which aren't backed by a descriptor
(fopencookie() in GNU, funopen() in BSD), so working with FILE* is
slightly more general.

[toc] | [prev] | [next] | [standalone]

#9459

On 08/30/11 03:40 PM, Nobody wrote:
> On Tue, 30 Aug 2011 07:49:06 +1200, Ian Collins wrote:
>
>>> Sure, the programmer can implement something themselves. But given how
>>> many programs will end up needing this (how many C++ programs use
>>> third-party libraries which use FILE*?), it seems like an oversight.
>>
>> A lot less than those that use a file descriptor.  Certainly in the Unix
>> world, FILE* is seldom used and integer file descriptors are pretty much
>> universal.
>
> That isn't my experience. Both are common enough that I couldn't say which
> of the two is the more popular. Descriptors tend to be used where
> buffering is likely to get in the way (e.g. binary I/O), FILE* where
> it's likely to be useful (e.g. text I/O). System calls use descriptors.
> Libraries which aim to be cross-platform tend to use FILE*.

Descriptors are used where the 'file' isn't a regular file (or in the 
case of popen, a pipe).  A FILE* isn't much use for a socket or a door 
for instance.

> An odd case is that popen() uses FILE*; possibly because programs are more
> likely to read/write text than binary via stdin/stdout, and that's easier
> to do with buffered streams.
>
> Ultimately, it doesn't make a great deal of difference, given the
> availability of fdopen() and fileno(). One exception is that some
> platforms support "user" streams which aren't backed by a descriptor
> (fopencookie() in GNU, funopen() in BSD), so working with FILE* is
> slightly more general.

For streams which read/write a regular file.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c++

csiph-web