What are the pros/cons of these approaches to File I/O under Windows using either VC++ or MinGW g++
Windows api (CreateFile,Read,Write)
<cstdio> (stdio.h)
<fstream>
Is it a user preference or are there concrete reasons to use one over the other?
Thank you for your input.
James
How portable do you want your code to be?
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
Portable How? vc++ <-> g++Originally Posted by Salem
Otherwise it is posted in the Windows forum
James
Salem's point is that any portability needed of your code (between compilers, between operating systems, or both) is one consideration in which approach you use.
Code that only works when built with a particular compiler patch level, a particular library, or a particular version of an operating system is vastly different from code that works for all possible compilers on most operating systems you can think of.
Last edited by grumpy; 11-02-2014 at 04:56 AM.
I should wait until I have my second cup of coffee before posting anywhere
For OS: MS Supported -> Vista+
These are the compilers that I use :
vc++ 18.00.21005.1 (Visual Studio Express 2013)
g++ TDM-GCC (TDM-GCC : News), NUWEN (MinGW Distro - nuwen.net)
primarily 64bit sometimes 32bit where available (NUWEN is 64bit only)
Compatibility between compilers would rank high on my wish list but I would be interested in those areas that are not compatible.
Thanks again,
James
I suppose you summed it up in your first post.
CreateFile et al is just an API provided by your operating system.
Any decent port of a compiler to your OS would give you the means to access that API.
cstdio and fstream are part of the language, and as such any compliant compiler (on any OS) would be expected to support them.
Using the core language features means you only have to learn something once. It generally makes life easier when you need to do the same or similar elsewhere.
The only reason for going for the platform API would be that it might give you a performance edge in some circumstances.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
In order of ease of use:
1) C++ I/O
2) C I/O
3) Platform I/O
Libraries (such as serialization libraries) are also often built on C/C++ I/O and not platform I/O, so unless you really need the extra performance or flexibility that the platform I/O may provide, you're better off with going with the standard library I/O facilities. If you're using C++, obviously you want to prioritize C++ API first over C.
Also, all but Microsoft's compiler tend to have some problems compiling the Windows headers (because they typically use Microsoft extensions), so if you want to avoid headaches and use multiple compilers, just stick to standard C/C++.
Yes, and contrary to what Salem said, there are other reasons besides performance to use the OS's API.
Some APIs allow you to operate on files relative to already open files, as any sane FS API would (though the WinAPI is not one of them). The C standard API does not.
The C standard API doesn't provide anything but the most primitve capabilities. This is understandable, but most applications beyond a small utility are probably going to need more advanced things, now while you can mix and match use of the APIs to a certain degree, it's very bad form, so you'll end up completely using the OS's API anyway.
But the good news is that the WinAPI, POSIX, and most other OS APIs make it very easy to handle files, so it's not too much extra work to use them.
I have been using fstream (probably not correctly).
How would you use the Windows api to duplicate this little snippet?
James
Code:#include <iostream> #include <fstream> #include <string> using namespace std; int main () { string sLine; fstream f; f.open("Test.txt", ios::in); if(f.is_open()) { while(f.good()) { getline(f, sLine); cout << sLine << endl; } } f.close(); }
Fixed and simplified code (don't poll a stream's state; check whether the read failed or not).
Use the constructor and destructor.
Code:#include <iostream> #include <fstream> #include <string> int main () { std::string sLine; std::ifstream f("Test.txt"); if (!f) // An error occured return 0; while (std::getline(f, sLine)) std::cout << sLine << std::endl; }
Last edited by Elysia; 11-02-2014 at 05:41 PM.
Elysia,
Thank you for the fix.
I have done some searching but the only (non-STL) examples I can find use mfc, .net (C++/CLI), or cstdio.
James
stdio.h/fgetc() is the best file i/o api :-)
Useless post of the month.
Don't be so brazen, I'm sure he's the brightest Awesometown's got.
why yarin? why??!
I wasnt being egoistic by calling myself citizen of awesometown...it was just a tribute to the forever awesome Govtcheese, the only person here who knows what true humour is.
*goes and cries in a corner*
xD
