how to use the fwrite () in C ++

[pal]

Hi all,


Could you help me how to use the fwrite( ) in C ++

 

[Pascal J. Bourguignon]

Could you help me how to use the fwrite( ) in C ++

It's exactly the same as in C.

 

[mlimber]

Could you help me how to use the fwrite( ) in C ++

Either be more specific or try Googling for it. I found this code
sample on the first page of search results:

http://msdn.microsoft.com/en-us/library/kt0etdcs(VS.71).aspx

Cheers! --M

 

[Juha Nieminen]

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.

 

[Alp Mestan]

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

 

[James Kanze]

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

Masochism? Obfuscation?

 

[Matthias Buelow]

Masochism? Obfuscation?

When using std:i|o)fstream, that is.

 

[Juha Nieminen]

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

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

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

 

[Juha Nieminen]

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".

 

[Default User]

Pete Becker wrote:

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

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





Brian

 

[Juha Nieminen]

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."

 

[Default User]

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

 

[James Kanze]

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

(And this is *only* for std:fstream::write(). Any of the
other functions of std: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]

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.

 

[Juha Nieminen]

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.

 

[Jerry Coffin]

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.

 

[James Kanze]

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.)