Making new files c++
I know how to open and read/write stuff with C++ and C, but how does one create a *new* file. Is it possible? :p
I'm gonna take a wild guess and say that just opening a file with the name you want (a file that does not already exist) does not work. I'll take another stab at guessing and say that it requires the systems internal indexes, perhaps?
Any help would be nice.
Thanks!
Wild guesses are really no substitute for trying things out or reading the documentation. Did you actually try using fopen() or ofstream with a new file name? Or did you look at your compiler's documentation for the fopen() function or the ofstream class?
If you do this:
std::ofstream fout("some_new_file.txt", std::ofstream::out);
It will truncate (clear) "some_new_file.txt" if the file exists, and will create a new one if not. However, this would only have taken you about 10 seconds to figure out on your own via simple experimentation, so I encourage you to try that in the future :)
std::ofstream fout("some_new_file.txt", std::ofstream::out);
It will truncate (clear) "some_new_file.txt" if the file exists, and will create a new one if not. However, this would only have taken you about 10 seconds to figure out on your own via simple experimentation, so I encourage you to try that in the future :)
It is usually best to stick with the Standard C Library functions instead of the C++ libraries whever possible. There are many reasons for this, but they are irrelevent for this thread.
I suggest you create a new file in the following way.
1) Define a file pointer: FILE *out;
2) "Open" a file and associate it with the pointer (opening a nonexistant file creates the file), in write mode:
out = fopen(filename, "w");
You have now created the file, now you can manipulate it in whatever way you choose. You can write to it (preferably with fwrite, fprintf -- or one of its variants, fputs, or one of a whole bunch of other functions). You can read to it (fread, DO NOT use fscanf -- as it is extremely unreliable unless used properly, etc). etc etc etc.
If you want to work with an existing file, replace the "w" in the call to fopen() with "r" to open in read-only mode, or "a" to open in append mode (opens the file, but automatically sets the pointer to the end of the file), or one of a number of advanced file access modes.
I suggest you create a new file in the following way.
1) Define a file pointer: FILE *out;
2) "Open" a file and associate it with the pointer (opening a nonexistant file creates the file), in write mode:
out = fopen(filename, "w");
You have now created the file, now you can manipulate it in whatever way you choose. You can write to it (preferably with fwrite, fprintf -- or one of its variants, fputs, or one of a whole bunch of other functions). You can read to it (fread, DO NOT use fscanf -- as it is extremely unreliable unless used properly, etc). etc etc etc.
If you want to work with an existing file, replace the "w" in the call to fopen() with "r" to open in read-only mode, or "a" to open in append mode (opens the file, but automatically sets the pointer to the end of the file), or one of a number of advanced file access modes.
Quote:Original post by medevilenemy
It is usually best to stick with the Standard C Library functions instead of the C++ libraries whever possible. There are many reasons for this, but they are irrelevent for this thread.
If you are coding in C++, it's best to use the C++ standard library, not the C one. What possible reasons could you have for not using STL?
Quote:Original post by medevilenemy
It is usually best to stick with the Standard C Library functions instead of the C++ libraries whever possible. There are many reasons for this, but they are irrelevent for this thread.
You cannot make a blanket statement and then refuse to justify it.
Quote:Original post by medevilenemy
It is usually best to stick with the Standard C Library functions instead of the C++ libraries whever possible. There are many reasons for this, but they are irrelevent for this thread.
Verily, I banish thee. Begone with yon ill advice.
Quote:Original post by JohnnyCasilQuote:Original post by medevilenemy
It is usually best to stick with the Standard C Library functions instead of the C++ libraries whever possible. There are many reasons for this, but they are irrelevent for this thread.
If you are coding in C++, it's best to use the C++ standard library, not the C one. What possible reasons could you have for not using STL?
Quote:Original post by kordova
You cannot make a blanket statement and then refuse to justify it.
Quote:Original post by Zahlman
Verily, I banish thee. Begone with yon ill advice.
Agreed. It seems I've already rated medevilenemy down the maximum amount for previous bad advice, unfortunately.
In this context, allow me to give an example list of rationale as to why the C++ standard library is superior in this case.
1) RAII.
With the C style fopen/fclose idiom, cleanup must be performed manually. This means before falling off the end of the function, before returning, or in the case of an exception being thrown. All and all, this can lead to some really nasty spaghetti, especially if the function is dealing with multiple resources that must be freed.
In contrast, std::fstream's derivations will automatically close the underlying stream upon their destruction via destructor. This means the stream will automatically be closed when falling off the end of the function, when returning, or if an exception is thrown. Zero extra overhead or effort must be expended to produce correctly functioning code.
Clear winner: C++ Standard Library.
2) Operator chaining.
With the C style printf/fprintf/snprintf, types must be specified manually in the format string. This means that every time you call these funcitons, you must explicitly tie it to the variable(s) type. All and all, this leads to some very brittle code, as every line that prints that variable breaks every time you change the type.
Your compiler may not even warn if the types mismatch, the format specifiers mismatches the number of arguments, or if you pass an object, all situations which lead to undefined behavior, the bane of programmers everywhere.
In contrast, std::[i/o]stream's derivations use operator chaining (the operators << and >> returning the original left handed argument) to accomplish the same task. Since this does not depend on the C varargs mechanism, no format string is required to indicate the appropriate types, and is thus impossible to get wrong, and will not cause breaks if you change the type. Further, it is impossible to mismatch the number of arguments to format specifiers, or pass in an object which does not have an appropriate stream operator defined (and it will work correctly if it is defined, unlike [f/sn/etc]printf which have no mechanism for plugging in such behavior).
Clear winner: C++ Standard Library.
[Edited by - MaulingMonkey on July 18, 2006 1:55:32 AM]
While I agree that using C functions in C++ code is bad, I think your reasoning is broken :)
Ok, how many times do you really change the type, and when writing to file, you sometimes want to know the exact contents of the file that you produce, not "oh, let's get lucky and remember that this variable has to be of this type so that our file meets the standard we're trying to follow with it". So that's not always good thing, sometimes you want to be sure that the output_the_file() function/method does exactly what you want and does not depend how you define your struct/class/variables/whatever.
Then again, your compiler may not, this has nothing to do with the language. If your compiler is at fault, it's not the language or the functions. Let's not assume what kind of compiler each uses.
Quote:Original post by MaulingMonkey
With the C style printf/fprintf/snprintf, types must be specified manually in the format string. This means that every time you call these funcitons, you must explicitly tie it to the variable(s) type. All and all, this leads to some very brittle code, as every line that prints that variable breaks every time you change the type.
Ok, how many times do you really change the type, and when writing to file, you sometimes want to know the exact contents of the file that you produce, not "oh, let's get lucky and remember that this variable has to be of this type so that our file meets the standard we're trying to follow with it". So that's not always good thing, sometimes you want to be sure that the output_the_file() function/method does exactly what you want and does not depend how you define your struct/class/variables/whatever.
Quote:
Your compiler may not even warn if the types mismatch, the format specifiers mismatches the number of arguments, or if you pass an object, all situations which lead to undefined behavior, the bane of programmers everywhere.
Then again, your compiler may not, this has nothing to do with the language. If your compiler is at fault, it's not the language or the functions. Let's not assume what kind of compiler each uses.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement