CreateFile vs fopen

[Harish]

Hello,

I read in a tech article that fopen()
should be discouraged and CreateFile()
should be used. What are the advantages
of CreateFile() over fopen()?
(I know about sharing open files which
cannot be done with fopen()).

Should using malloc() also be discouraged?

Thanks in advance
Harish

[Jochen Kalmbach]

Post by Harish
I read in a tech article that fopen()
should be discouraged and CreateFile()
should be used. What are the advantages
of CreateFile() over fopen()?
(I know about sharing open files which
cannot be done with fopen()).

fread is ANSI-C
CreateFile is Win32-API

fread internally uses CreateFile on Windows-Platforms

So if your program should be portable you should use fopen, if not you can
use what you want.

Post by Harish
Should using malloc() also be discouraged?

You can also use LocalAlloc.
But if you do not use malloc then you should consequently not use ANY of
the C-Runtime functions (like strcpy, fopen, va_start, abs, div, mod,
printf, memcpy, assert, time; and many other)

[Arkady Frenkel]

Additionally : I found before many years ( it was on W95 ) when I did
private read of INI ( only 64K section possible read there ) that fopen work
much quicker ( as I can understand use internal bufferization to return
previously read blocks of data )
Arkady

Post by Jochen Kalmbach

Post by Harish
I read in a tech article that fopen()
should be discouraged and CreateFile()
should be used. What are the advantages
of CreateFile() over fopen()?
(I know about sharing open files which
cannot be done with fopen()).

fread is ANSI-C
CreateFile is Win32-API
fread internally uses CreateFile on Windows-Platforms
So if your program should be portable you should use fopen, if not you can
use what you want.

Post by Harish
Should using malloc() also be discouraged?

You can also use LocalAlloc.
But if you do not use malloc then you should consequently not use ANY of
the C-Runtime functions (like strcpy, fopen, va_start, abs, div, mod,
printf, memcpy, assert, time; and many other)
--
Greetings
Jochen
Do you need a memory-leak finder ?
http://www.codeproject.com/tools/leakfinder.asp

[Carey Gregory]

Post by Arkady Frenkel
Additionally : I found before many years ( it was on W95 ) when I did
private read of INI ( only 64K section possible read there ) that fopen work
much quicker ( as I can understand use internal bufferization to return
previously read blocks of data )

Probably because it ignores the serializations that the INI file functions
provide. That might make it faster, but it also makes it unreliable.


--
Carey Gregory
Windows Print Drivers & Components
http://www.gw-tech.com

[Fenster]

Post by Jochen Kalmbach
But if you do not use malloc then you should consequently not use ANY of
the C-Runtime functions (like strcpy, fopen, va_start, abs, div, mod,
printf, memcpy, assert, time; and many other)

Why is that? Is it from MSDN?

[Jochen Kalmbach]

Post by Fenster

Post by Jochen Kalmbach
But if you do not use malloc then you should consequently not use ANY of
the C-Runtime functions (like strcpy, fopen, va_start, abs, div, mod,
printf, memcpy, assert, time; and many other)

Why is that? Is it from MSDN?

No it is from me.

[Carey Gregory]

Post by Jochen Kalmbach

Post by Fenster

Post by Jochen Kalmbach
But if you do not use malloc then you should consequently not use ANY of
the C-Runtime functions (like strcpy, fopen, va_start, abs, div, mod,
printf, memcpy, assert, time; and many other)

Why is that? Is it from MSDN?

No it is from me.

I would agree that you should be careful which runtime functions you use if
you're avoiding malloc since some of them use it internally, but the runtime
library isn't an all or nothing choice. You might have a legitimate need
for a different memory manager, but that doesn't mean you can't or shouldn't
use other runtime functions.

But as originally pointed out, fopen uses CreateFile internally on Win32
platforms. There's no good reason to choose it over fopen unless you need
the additional functionality of CreateFile.


--
Carey Gregory
Windows Print Drivers & Components
http://www.gw-tech.com