It IS listedOriginally Posted by Elysia
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
Yes, stupid Microsoft. They tend to hide away such information.
Guess you'll have to rely on API after all.
The flags can still come in handy when you know you will be writing windows only code anyway
It only works in Visual Studio, so it's not portable code since it won't work with other IDEs or compilers.
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
ahem, Bloodshed, which uses GCC, supports WinAPI, so the code is portable to other IDE/Compilers, just not to other OS's, except Linux has windows emulation now, so nevermind, windows code is fully portable.
I wouldn't go that far.
Not the API, but the Microsoft CRT extensions.
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); } }
Are you kidding us?
pname is 4 x 10 ^ 9 bytes long, it's global, datasave doesn't return anything, you open for reading and writing and you write an unfilled buffer.
Yes, it's really works well, doesn't it?
Yes it does work. Global data should be gobal not local, hence it is global.Are you kidding us?
pname is 4 x 10 ^ 9 bytes long, it's global, datasave doesn't return anything, you open for reading and writing and you write an unfilled buffer.
Yes, it's really works well, doesn't it?
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.
Nope no crash.
You are asuming the integer size is 4, I am assuming it is 1.
Eitherway no crash.
