It IS listed
http://msdn2.microsoft.com/en-us/lib...cb(VS.80).aspxThe c, n, t, S, R, T and D mode options are Microsoft extensions for fopen and _fdopen and should not be used where ANSI portability is desired.
See Requirements section
It IS listed
http://msdn2.microsoft.com/en-us/lib...cb(VS.80).aspxThe c, n, t, S, R, T and D mode options are Microsoft extensions for fopen and _fdopen and should not be used where ANSI portability is desired.
See Requirements section
All problems in computer science can be solved by another level of indirection,
except for the problem of too many layers of indirection.
– David J. Wheeler
The flags can still come in handy when you know you will be writing windows only code anyway
DevC++ / Mingw uses the Microsoft CRT DLL (MSVCRT.dll) - so MS CRT extensions could be used if you like.
However, you need to use the Visual Studio 6.0 CRT documentation to see what's available:
http://msdn2.microsoft.com/en-us/lib...92(VS.60).aspx
gg
AFAIK the CRT on windows comes in a Dll too, so its perfectly possible to use microsft extensions like the fopen flags from other compilers. You just need to link to the MSVCRTxx.dll
Yes, but it's still ONLY going to work that way in a Microsoft environment.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
Use a loop to fill pname with f's.
Then use this.
That is the fastest possible way.
Code:FILE *dataptr; int pname[1000000000]; datasave(){ if ( (dataptr=fopen("data.doc", "wb+" )) != NULL) { fwrite( pname, sizeof( pname ), 1, dataptr); fclose(dataptr); } else { puts("\nCant creat datafile"); exit(2); } }
Yes it does work. Global data should be gobal not local, hence it is global.
Passing around 4 gigabytes of data within a program would be bordering on insanity.
It is open for reading and writing because that is how it was used in the origninal
program where the code was copied from. The user never implied that reading the file
should be restricted so there was no reason to restrict it in the example.
To do so would thus be rather pointless.
There is nothing to return.
It is implicit that the trivial matter filling of the buffer is not shown for brevity.
The function rightly aborts immediately when it encounters a fatal error, this saves
each call to the function duplicating the code unnecessarilly.
Does not work.
4 x 1000000000 / 1024 / 1024 / 1024 = 3814,697265625 ~= 4 GB.
Oops! Insta crash!
Global variables and global data should be avoided.Global data should be gobal not local, hence it is global.
And what exactly do you think you're doing?Passing around 4 gigabytes of data within a program would be bordering on insanity.
That is ridiculous. If the only thing you do is write, then only open it for writing.It is open for reading and writing because that is how it was used in the origninal
program where the code was copied from. The user never implied that reading the file
should be restricted so there was no reason to restrict it in the example.
To do so would thus be rather pointless.
Otherwise consider adding a read or just a pseudo /* Read something here */ comment.
Yes, there is. Void.There is nothing to return.
Then add a pseudo /* Fill buffer or reading something here */It is implicit that the trivial matter filling of the buffer is not shown for brevity.
No, it should return success or failure, just as I mentioned in the other post. A utility function should never explicitly terminate the program. That should be done by the main code. And there's a reason for that, too. To fix things, to recover, to clean up, etc.The function rightly aborts immediately when it encounters a fatal error, this saves
each call to the function duplicating the code unnecessarilly.