how to use the fwrite () in C ++

Discussion in 'C++' started by pal, Aug 14, 2008.

  1. pal

    pal Guest

    Hi all,


    Could you help me how to use the fwrite( ) in C ++
    pal, Aug 14, 2008
    #1
    1. Advertising

  2. pal <> writes:
    > Could you help me how to use the fwrite( ) in C ++


    It's exactly the same as in C.

    --
    __Pascal Bourguignon__
    Pascal J. Bourguignon, Aug 14, 2008
    #2
    1. Advertising

  3. pal

    mlimber Guest

    mlimber, Aug 14, 2008
    #3
  4. Pascal J. Bourguignon wrote:
    > pal <> writes:
    >> Could you help me how to use the fwrite( ) in C ++

    >
    > It's exactly the same as in C.


    Not *exactly*, at least not if your compiler strictly adheres to the
    C++ standard: You need to either use std::fwrite(), or pull it out of
    the namespace with a "using std::fwrite;".

    But otherwise yes, it works like in C.
    Juha Nieminen, Aug 14, 2008
    #4
  5. pal

    Alp Mestan Guest

    But is there a special reason for using fwrite instead of C++ streams
    (std::(i|o)fstream) ?
    Alp Mestan, Aug 14, 2008
    #5
  6. pal

    James Kanze Guest

    On Aug 14, 11:16 pm, Alp Mestan <> wrote:
    > But is there a special reason for using fwrite instead of C++
    > streams (std::(i|o)fstream) ?


    Masochism? Obfuscation?

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Aug 14, 2008
    #6
  7. James Kanze wrote:

    >> But is there a special reason for using fwrite instead of C++
    >> streams (std::(i|o)fstream) ?

    >
    > Masochism? Obfuscation?


    When using std::(i|o)fstream, that is.
    Matthias Buelow, Aug 14, 2008
    #7
  8. Alp Mestan wrote:
    > But is there a special reason for using fwrite instead of C++ streams
    > (std::(i|o)fstream) ?


    Speed. Some implementations of std::eek:fstream::write() may parallel the
    speeds of std::fwrite(), but many don't.

    (And this is *only* for std::eek:fstream::write(). Any of the other
    functions of std::eek:fstream will be hopelessly slower than std::fwrite().)
    Juha Nieminen, Aug 14, 2008
    #8
  9. Pete Becker wrote:
    > On 2008-08-14 13:43:27 -0400, Juha Nieminen <> said:
    >
    >> Pascal J. Bourguignon wrote:
    >>> pal <> writes:
    >>>> Could you help me how to use the fwrite( ) in C ++
    >>>
    >>> It's exactly the same as in C.

    >>
    >> Not *exactly*, at least not if your compiler strictly adheres to the
    >> C++ standard: You need to either use std::fwrite(), or pull it out of
    >> the namespace with a "using std::fwrite;".

    >
    > No, you need std:: only if you use <cstdio>. If you use it *exactly* the
    > same as in C, with <stdio.h>, you use it *exactly* the same as in C,
    > with no namespace.


    IIRC, the C++ standard doesn't define the header "stdio.h", only "cstdio".
    Juha Nieminen, Aug 14, 2008
    #9
  10. pal

    Default User Guest

    Juha Nieminen wrote:

    > Pete Becker wrote:


    > > No, you need std:: only if you use <cstdio>. If you use it exactly
    > > the same as in C, with <stdio.h>, you use it exactly the same as in
    > > C, with no namespace.

    >
    > IIRC, the C++ standard doesn't define the header "stdio.h", only
    > "cstdio".


    You don't recall correctly. It is standard, although deprecated.





    Brian
    Default User, Aug 14, 2008
    #10
  11. Alf P. Steinbach wrote:
    > In C++0x <cstdio> is allowed to bring the symbols into the global
    > namespace, as is the practice with current compilers, but which
    > undermines the whole scheme.


    I really can't understand why.

    If the idea is to make a compromise with old code (why should a
    compromise be made in the first place?), why not simply formalize the
    <stdio.h> bringing all to the global namespace rather than break the
    current convention of <cstdio> not doing so?

    All this sounds crazy to me. It's like the standardization committee
    is thinking like: "Hmm, it would be nice to deprecate <stdio.h> and
    libraries inherited from C putting all into the global namespace, but
    tons and tons of code out there is ignoring all this, using <stdio.h>
    anyways, and assuming that everything is global. What should we do? I
    know, let's keep <stdio.h> deprecated, but instead let's allow <cstdio>
    to make everything global. That will work."

    That sounds like the stupidest idea ever. It not only doesn't fix the
    problem (ie. people using <stdio.h>), but completely nullifies the whole
    idea of the std namespace and keeping the global namespace cleaner (at
    least with respect to C library functions). It's like a "let's *not*
    compromise with the *actual* problem, but instead let's break the
    current modularity conventions."
    Juha Nieminen, Aug 15, 2008
    #11
  12. pal

    Default User Guest

    Juha Nieminen wrote:

    > Alf P. Steinbach wrote:
    > > In C++0x <cstdio> is allowed to bring the symbols into the global
    > > namespace, as is the practice with current compilers, but which
    > > undermines the whole scheme.

    >
    > I really can't understand why.
    >
    > If the idea is to make a compromise with old code (why should a
    > compromise be made in the first place?), why not simply formalize the
    > <stdio.h> bringing all to the global namespace rather than break the
    > current convention of <cstdio> not doing so?


    It is formalized. See the standard, Appendix D.




    Brian
    Default User, Aug 15, 2008
    #12
  13. pal

    James Kanze Guest

    On Aug 14, 11:50 pm, Juha Nieminen <> wrote:
    > Alp Mestan wrote:
    > > But is there a special reason for using fwrite instead of
    > > C++ streams (std::(i|o)fstream) ?


    > Speed. Some implementations of std::eek:fstream::write() may
    > parallel the speeds of std::fwrite(), but many don't.


    > (And this is *only* for std::eek:fstream::write(). Any of the
    > other functions of std::eek:fstream will be hopelessly slower
    > than std::fwrite().)


    If speed's an issue, the best results can usually be had by
    going down to the level of the system. The added "abstraction"
    of fwrite (or fstream, in this case) doesn't really buy you
    anything. (This is, of course, only true when you're not doing
    any formatting.)

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Aug 15, 2008
    #13
  14. pal

    James Kanze Guest

    On Aug 15, 1:30 am, Juha Nieminen <> wrote:
    > Alf P. Steinbach wrote:
    > > In C++0x <cstdio> is allowed to bring the symbols into the global
    > > namespace, as is the practice with current compilers, but which
    > > undermines the whole scheme.


    > I really can't understand why.


    > If the idea is to make a compromise with old code (why should a
    > compromise be made in the first place?), why not simply formalize the
    > <stdio.h> bringing all to the global namespace rather than break the
    > current convention of <cstdio> not doing so?


    I sort of agree. As Pete points out, the compromize is there
    for the case (quite frequent, in my experience) where the C++
    library authors don't control the C headers. Requiring the
    implementation to "do the right thing" would basically mean
    requiring them to reimplement all of the C library again. For
    very, very little benefit. Given this, however, it seems to me
    that a more reasonable solution would have been to simply
    require the presence of <stdio.h>, defined exactly as in C, and
    be done with it. (On the other hand, the current situation does
    allow an implementation to do the right thing, if it does have
    the possibility.)

    > All this sounds crazy to me. It's like the standardization committee
    > is thinking like: "Hmm, it would be nice to deprecate <stdio.h> and
    > libraries inherited from C putting all into the global namespace, but
    > tons and tons of code out there is ignoring all this, using <stdio.h>
    > anyways, and assuming that everything is global. What should we do? I
    > know, let's keep <stdio.h> deprecated, but instead let's allow <cstdio>
    > to make everything global. That will work."


    > That sounds like the stupidest idea ever. It not only doesn't fix the
    > problem (ie. people using <stdio.h>), but completely nullifies the whole
    > idea of the std namespace and keeping the global namespace cleaner (at
    > least with respect to C library functions). It's like a "let's *not*
    > compromise with the *actual* problem, but instead let's break the
    > current modularity conventions."


    I wouldn't go that far. It allows you to write things like
    std::remove( filename ), on one hand, making it clear to the
    reader that you are using a standard function, and on the other,
    disambiguating if you happen to be in a class which has a member
    function named remove as well.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Aug 15, 2008
    #14
  15. James Kanze wrote:
    > If speed's an issue, the best results can usually be had by
    > going down to the level of the system.


    Which is what fwrite() does. And it's much easier to use than system
    calls.
    Juha Nieminen, Aug 15, 2008
    #15
  16. pal

    Jerry Coffin Guest

    In article <Ulbpk.65$>, lid
    says...
    > James Kanze wrote:
    > > If speed's an issue, the best results can usually be had by
    > > going down to the level of the system.

    >
    > Which is what fwrite() does. And it's much easier to use than system
    > calls.


    At least IME, fwrite always imposes some buffering on top of what the
    system does. Offhand, I don't see a whole lot of difference between
    fwrite and POSIX write in terms of ease of use.

    --
    Later,
    Jerry.

    The universe is a figment of its own imagination.
    Jerry Coffin, Aug 15, 2008
    #16
  17. pal

    James Kanze Guest

    On Aug 15, 10:44 am, Juha Nieminen <> wrote:
    > James Kanze wrote:
    > > If speed's an issue, the best results can usually be had by
    > > going down to the level of the system.


    > Which is what fwrite() does. And it's much easier to use than
    > system calls.


    fwrite() buffers. (So do the system calls, at least under Unix,
    but fwrite() buffers a second time.) fwrite() also takes two
    arguments for the size, which it multiplies. I can't see any
    case where that makes sense.

    IMHO, fwrite() is a hangover from a time where the problems with
    directly copying a struct to and from disk weren't
    understood---and also mattered a lot less. So it can be called
    with the address of a struct, sizeof the same struct, and the
    number of instances we want to write. Today, of course, we know
    that that doesn't work in practice, over time, and that it is a
    source of problems later. (Thus, the iostream read and write
    functions take char* and a single size---they are designed for
    reading and writing preformatted data, which can be done
    correctly.)

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Aug 16, 2008
    #17
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. nescio
    Replies:
    0
    Views:
    447
    nescio
    Dec 21, 2005
  2. nescio

    fwrite() question

    nescio, Dec 21, 2005, in forum: HTML
    Replies:
    0
    Views:
    359
    nescio
    Dec 21, 2005
  3. seia0106
    Replies:
    3
    Views:
    3,113
    Jack Klein
    Jul 18, 2003
  4. Zalek Bloom
    Replies:
    2
    Views:
    736
    llewelly
    Sep 9, 2003
  5. mazsx
    Replies:
    2
    Views:
    853
    Toni Uusitalo
    Nov 11, 2005
Loading...

Share This Page