By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,919 Members | 1,074 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,919 IT Pros & Developers. It's quick & easy.

how to use the fwrite () in C ++

P: n/a
pal
Hi all,
Could you help me how to use the fwrite( ) in C ++
Aug 14 '08 #1
Share this Question
Share on Google+
19 Replies


P: n/a
pal <ja********@gmail.comwrites:
Could you help me how to use the fwrite( ) in C ++
It's exactly the same as in C.

--
__Pascal Bourguignon__
Aug 14 '08 #2

P: n/a
On Aug 14, 10:28*am, pal <jayapal...@gmail.comwrote:
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/libr...cs(VS.71).aspx

Cheers! --M
Aug 14 '08 #3

P: n/a
Pascal J. Bourguignon wrote:
pal <ja********@gmail.comwrites:
>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.
Aug 14 '08 #4

P: n/a
On 2008-08-14 13:43:27 -0400, Juha Nieminen <no****@thanks.invalidsaid:
Pascal J. Bourguignon wrote:
>pal <ja********@gmail.comwrites:
>>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.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

Aug 14 '08 #5

P: n/a
But is there a special reason for using fwrite instead of C++ streams
(std::(i|o)fstream) ?
Aug 14 '08 #6

P: n/a
On Aug 14, 11:16 pm, Alp Mestan <alpmes...@gmail.comwrote:
But is there a special reason for using fwrite instead of C++
streams (std::(i|o)fstream) ?
Masochism? Obfuscation?

--
James Kanze (GABI Software) email:ja*********@gmail.com
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
Aug 14 '08 #7

P: n/a
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.
Aug 14 '08 #8

P: n/a
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::ofstream::write() may parallel the
speeds of std::fwrite(), but many don't.

(And this is *only* for std::ofstream::write(). Any of the other
functions of std::ofstream will be hopelessly slower than std::fwrite().)
Aug 14 '08 #9

P: n/a
Pete Becker wrote:
On 2008-08-14 13:43:27 -0400, Juha Nieminen <no****@thanks.invalidsaid:
>Pascal J. Bourguignon wrote:
>>pal <ja********@gmail.comwrites:
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".
Aug 14 '08 #10

P: n/a
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
Aug 14 '08 #11

P: n/a
Alf P. Steinbach wrote:
In C++0x <cstdiois 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.hbringing all to the global namespace rather than break the
current convention of <cstdionot 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.hand
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.hdeprecated, 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."
Aug 14 '08 #12

P: n/a
Juha Nieminen wrote:
Alf P. Steinbach wrote:
In C++0x <cstdiois 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.hbringing all to the global namespace rather than break the
current convention of <cstdionot doing so?
It is formalized. See the standard, Appendix D.


Brian
Aug 15 '08 #13

P: n/a
On 2008-08-14 17:51:41 -0400, Juha Nieminen <no****@thanks.invalidsaid:
Pete Becker wrote:
>On 2008-08-14 13:43:27 -0400, Juha Nieminen <no****@thanks.invalidsaid:
>>Pascal J. Bourguignon wrote:
pal <ja********@gmail.comwrites:
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".
That's right: it defers to the C standard for the contents of
<stdio.h>. But incorporation by reference is no less legitimate than
explicit definition.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

Aug 15 '08 #14

P: n/a
On 2008-08-14 19:30:03 -0400, Juha Nieminen <no****@thanks.invalidsaid:
Alf P. Steinbach wrote:
>In C++0x <cstdiois 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.
The reason is simply that it can't be implemented if the C++
implementor doesn't control the C headers, which is not uncommon. The
change recognizes reality.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

Aug 15 '08 #15

P: n/a
On Aug 14, 11:50 pm, Juha Nieminen <nos...@thanks.invalidwrote:
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::ofstream::write() may
parallel the speeds of std::fwrite(), but many don't.
(And this is *only* for std::ofstream::write(). Any of the
other functions of std::ofstream 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:ja*********@gmail.com
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
Aug 15 '08 #16

P: n/a
On Aug 15, 1:30 am, Juha Nieminen <nos...@thanks.invalidwrote:
Alf P. Steinbach wrote:
In C++0x <cstdiois 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.hbringing all to the global namespace rather than break the
current convention of <cstdionot 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.hand
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.hdeprecated, 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:ja*********@gmail.com
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
Aug 15 '08 #17

P: n/a
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.
Aug 15 '08 #18

P: n/a
In article <Ul*************@read4.inet.fi>, no****@thanks.invalid
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.
Aug 15 '08 #19

P: n/a
On Aug 15, 10:44 am, Juha Nieminen <nos...@thanks.invalidwrote:
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:ja*********@gmail.com
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
Aug 16 '08 #20

This discussion thread is closed

Replies have been disabled for this discussion.