how to use the fwrite () in C ++

[pal]

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

[Pascal J. Bourguignon]

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__

[mlimber]

On Aug 14, 10:28*am, pal <[e-mail]:

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

[Juha Nieminen]

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.

[Pete Becker]

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)

[Alp Mestan]

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

[James Kanze]

On Aug 14, 11:16 pm, Alp Mestan <[e-mail]:

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, [phone]

[Matthias Buelow]

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.

[Juha Nieminen]

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

[Juha Nieminen]

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

[Default User]

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

[Juha Nieminen]

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

[Default User]

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

[Pete Becker]

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)

[Pete Becker]

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)

[James Kanze]

On Aug 14, 11:50 pm, Juha Nieminen <[e-mail]:

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, [phone]

[James Kanze]

On Aug 15, 1:30 am, Juha Nieminen <[e-mail]:

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, [phone]

[Juha Nieminen]

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.

[Jerry Coffin]

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.

[James Kanze]

On Aug 15, 10:44 am, Juha Nieminen <[e-mail]:

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, [phone]