Professional Web Applications Themes

C++ streams and FILE* interoperability - UNIX Programming

I think streams are nice, but what do you do when you have to write to or, even worse, read from a FILE*, for example a UNIX stream? C++ streams can not be created from FILE*'s or have them attached. Today, a C++ programmer has to decide beforehand whether he wants to use C or C++ I/O. Suppose you choose C++ streams and write all of the "operator>>" code for your objects. If you later decide to read the same objects from a UNIX pipe, you'll have to rewrite and re-debug much of that code. Since C++ was aiming for ...

  1. #1

    Default C++ streams and FILE* interoperability

    I think streams are nice, but what do you do when you have to write to
    or, even worse, read from a FILE*, for example a UNIX stream?

    C++ streams can not be created from FILE*'s or have them attached.

    Today, a C++ programmer has to decide beforehand whether he wants to
    use C or C++ I/O. Suppose you choose C++ streams and write all of the
    "operator>>" code for your objects. If you later decide to read the
    same objects from a UNIX pipe, you'll have to rewrite and re-debug
    much of that code.

    Since C++ was aiming for seamless interoperability with C, wouldn't it
    have been easier to make its file stream a shallow wrapper around
    FILE*? It already has the necessary buffering functionality. Or at
    least specialize the character streams to be such bufferless wrappers
    around FILE* ?

    On a more positive note, I haven't used them yet, but it looks like
    STLport provides such shallow stream wrappers as an option.
    sb Guest

  2. #2

    Default Re: C++ streams and FILE* interoperability

    com (sb) writes:
     

    This isn't true. You can derive a streambuf class that will take a
    FILE* or file descriptor as a constructor parameter, and use that to
    get/send data. Josuttis gives an example of the latter in his book.

    Neither FILE* or file descriptor is portable though, which is why
    they're not supported in the C++ standard.
     

    Not if you do it right. It does take a pretty good understanding of
    how the classes work though.
     

    I wouldn't argue with that. However, if you're really interested in
    getting expert opinions about this (as opposed to random net.bozos
    like me) ask this is comp.lang.c++.moderated.

    Joe
    --
    "I didn't really say everything I said."
    - Yogi Berra
    joe@invalid.address Guest

  3. #3

    Default Re: C++ streams and FILE* interoperability

    In article <address>, address wrote:
     

    I understand that file descriptors wouldn't be portable, but why not
    FILE*? It's part of the C standard, and C++ incorporates most of C by
    reference.

    --
    Barry Margolin, mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    Barry Guest

  4. #4

    Default Re: C++ streams and FILE* interoperability

    Barry Margolin wrote:
     

    I think he meant wrapping a streambuf around a FILE * wouldn't be
    portable, not that FILE * themselves aren't portable.

    --
    __ Erik Max Francis && com && http://www.alcyone.com/max/
    / \ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
    \__/ Seriousness is the only refuge of the shallow.
    -- Oscar Wilde
    Erik Guest

  5. #5

    Default Re: C++ streams and FILE* interoperability

    address wrote:
     
    >
    > This isn't true. You can derive a streambuf class that will take a
    > FILE* or file descriptor as a constructor parameter, and use that to
    > get/send data. Josuttis gives an example of the latter in his book.[/ref]

    And, in fact, practically any Unix-based C++ Standard Library is going
    to have these available as extensions. Simply check your compiler
    manual.

    --
    __ Erik Max Francis && com && http://www.alcyone.com/max/
    / \ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
    \__/ Seriousness is the only refuge of the shallow.
    -- Oscar Wilde
    Erik Guest

  6. #6

    Default Re: C++ streams and FILE* interoperability

    Barry Margolin <mit.edu> writes:
     
    >
    > I understand that file descriptors wouldn't be portable, but why not
    > FILE*? It's part of the C standard, and C++ incorporates most of C
    > by reference.[/ref]

    I probably misspoke there. As you say, it should be portable to
    everywhere that C is (allowing for embedded environments that don't
    have struct FILE, etc). I've seen an example of a class that wrapped
    popen(), and it was more trouble than it was worth to me. YMMV.

    Joe
    --
    "I didn't really say everything I said."
    - Yogi Berra
    joe@invalid.address Guest

  7. #7

    Default Re: C++ streams and FILE* interoperability

    Erik Max Francis wrote:
     

    "Portable" wasn't the right word, here; I meant part of the Standard
    Library, not portable. i.e., if you were using such a thing without
    writing it yourself, you're relying on an implementation extension, not
    a Standard feature.

    --
    __ Erik Max Francis && com && http://www.alcyone.com/max/
    / \ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
    \__/ I have not yet begun to right!
    -- John Paul Jones
    Erik Guest

Similar Threads

  1. unexpected end of file on recorded streams
    By GenaroRG in forum Macromedia Flash Flashcom
    Replies: 3
    Last Post: January 2nd, 09:58 PM
  2. Replies: 1
    Last Post: February 26th, 09:04 AM
  3. Web services interoperability
    By Onder OZCAN in forum ASP.NET Web Services
    Replies: 0
    Last Post: February 5th, 12:06 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139