fopen with std::string

Im trying to find a way to open several files with different names.
My first problem creating this program is, how come that 'fopen()' which is a C++ function takes a C const char* argument?
I thought we were supposed to use strings with C++.

This is what i have so far, trying to figure out how to use strings.

Code:

---

#include <iostream>
#include <string>
using namespace std;


int main ()
{
  FILE * pFile;
  int i = 0;
  char ch[5] = {0,1,2,3,4};
  string str = "file.txt", str2;
  pFile = fopen (str,"w");
  while (i<5)
  {
    cout << "Enter word: "; cin >> str2;
    str.append(ch[i]);
    fprintf(pFile, str2);
    fclose (pFile);
    i++;
  }
  return 0;
}

---

Quote:

---

Originally Posted by Ducky

My first problem creating this program is, how come that 'fopen()' which is a C++ function takes a C const char* argument?
I thought we were supposed to use strings with C++.

---

Well, fopen() is actually inherited from the C standard library. That said, the C++ standard file streams also use a const char* parameter. The solution lies with the c_str() member function, e.g.,

Code:

---

pFile = fopen(str.c_str(), "w");

---

By the way, it looks like you are closing the file in the loop. Also, you should #include <cstdio> for std::fopen().

>> My first problem creating this program is, how come that 'fopen()' which is a C++ function takes a C const char* argument?

fopen is a C function (but still valid for C++, of course). Incidentally, fstreams also take a const char*, which I've always found a bit odd. Anyway, you just need to invoke the std::string::c_str( ) function to get a pointer to the bytes.

>> Incidentally, fstreams also take a const char*, which I've always found a bit odd.

I agree. I'm pretty sure it's fixed in the next standard.

Thank you Laserlight and Sebastiani!

"By the way, it looks like you are closing the file in the loop."
Yes you are right thanks for recalling me but on second thoughts if i wanna open a new file every time i think i would have to close the precedent.

I corrected the code. Now i just need to find out how to append a number each time to the filename.
For a reason 'strcpy' wont accept the first arg.

Code:

---

#include <cstdio>
#include <iostream>
#include <string>
using namespace std;


int main ()
{
 FILE * pFile;
  int i = 0;
  char ch[5] = {0,1,2,3,4};
  string filename = "file.txt", str2;
  pFile = fopen (filename.c_str(),"w");
  while (i<5)
  {
    cout << "Enter word: "; cin >> str2;
    strcpy(filename.c_str(), ch[i]);
    pFile = fopen (filename.c_str(),"w");
    fprintf(pFile, str2.c_str());
    fclose (pFile);
    i++;
  }
  return 0;
}

---

Quote:

---

Originally Posted by Ducky

Now i just need to find out how to append a number each time to the filename.

---

You can use a stringstream. Here is the idea expressed as an example program:

Code:

---

#include <sstream>
#include <string>
#include <iostream>

int main()
{
    using namespace std;

    const string filename = "file";
    const string extension = ".txt";
    for (int i = 0; i < 5; ++i)
    {
        stringstream ss;
        ss << filename << i << extension;
        cout << ss.str() << endl;
    }
}

---

Speaking of which, is there a reason why you are not using std::fstream?

>> strcpy(filename.c_str(), ch[i]);

>> For a reason 'strcpy' wont accept the first arg.

You should never alter an std::string like that - any function that potentially transforms the size of the bytes (with respect to the null terminator) will lead to undefined behaviour. Furthermore, character transforms are safe, of course, unless the resulting character is itself the null terminator for that character type. The correct way would be simply:

filename = ch[i];

EDIT:
I hadn't noticed the type of ch. Yes, use Laserlight's suggestion.

Thank you very much again both of you! :)

Of course, i forgot how easy it was to concatenate with strings, i just went complicating things again.:)

"is there a reason why you are not using std::fstream?"

No there isn't. Actually i just found this comparison between the two and it looks like std::fstream is faster.
So im gonna use std::fstream instead. Thank you!

http://social.msdn.microsoft.com/For...2-36248f86a8ce

Ok, have a good day or night everybody, whatever is it over there, its already night here. :)

Quote:

---

Originally Posted by Ducky

Actually i just found this comparison between the two and it looks like std::fstream is faster.

---

Read it again. The buffering is intensive. :devil:

"The buffering is intensive."

Is it a bad thing?

>> Is it a bad thing?

fstreams do have a bit more overhead, but you get what you pay for, and I think most would agree that the benefits outweigh the the drawbacks.

Just the fact that they use RAII is enough for me! And not to mention << and >>.

Ok, thanks Tux0r for your help!
I dont understand right now what you're saying but i will look after it later when i'll have the time.

For now i got Laserlight and Sebastiani telling me to prefer fstream so i rewrote the program with fstream.

For a reason 'cout' accepts stringstream ss.str() but 'filestr.open()' won't.

Code:

---

#include <iostream>
#include <string>
#include <sstream>
#include <fstream>

using namespace std;


int main ()
{
    fstream filestr;
    filestr.open ("test.txt", fstream::in | fstream::out | fstream::app);

    const string filename  = "file";
    const string extension = ".txt";
    stringstream ss;
    string word;

    for (int i = 0; i < 5; ++i)
    {
        cout << "Enter word: "; cin >> word;
        ss << filename << i << extension;
      filestr.open (ss.str(), fstream::in | fstream::out | fstream::app);
        filestr << word.c_str() << endl;
        filestr.close();
    }


    return 0;
}

---

Should be:

Code:

---

filestr.open (ss.str().c_str(), fstream::in | fstream::out | fstream::app);

---

Thank you! :)

Quote:

---

Originally Posted by Ducky

Ok, thanks Tux0r for your help!
I dont understand right now what you're saying but i will look after it later when i'll have the time.

For now i got Laserlight and Sebastiani telling me to prefer fstream so i rewrote the program with fstream.[/CODE]

---

I meant that I prefer C++ streams (like std::fstream) even with cstdio being faster...
Speed doesn't mean it's better to use in practice. ;)

For example you don't have to filestr.close(); if you don't feel like so.

Ah ok, i understand! :)

"For example you don't have to filestr.close(); if you don't feel like so. "
Really? Thats great! No disadvantage?

But in my program i have to because i recall it again and again.

Another thing. I tried to clear 'stringstream ss' with 'ss << "";' and 'ss.clear();'
but it didnt worked.
Then i saw that Laserlight redeclared it each time in the loop.
So the fact that redeclaring it, it clears its content.

Im just wondering if there is another way to do it.
I googled but found nothing apart 'ss << "";' and 'ss.clear();' .

Code:

---

ss.str("");
ss.clear()

---

Is the way to do it, I believe.

Quote:

---

Originally Posted by Ducky

Ah ok, i understand! :)
"For example you don't have to filestr.close(); if you don't feel like so. "
Really? Thats great! No disadvantage?

---

Not really, as the object is destructed, it frees appropriate resources

Code:

---

void lol() {
    std::ifstream f("lol");

    f<<"lol";
} //lol        just kidding... here "f" is closed automatically

---

Basically, a C++ fstream automatically closes itself when the object is destroyed. So in your example,

Code:

---

int main ()
{
    const string filename  = "file";
    const string extension = ".txt";
    stringstream ss;
    string word;

    for (int i = 0; i < 5; ++i)
    {
        cout << "Enter word: "; cin >> word;
        ss << filename << i << extension;
        fstream filestr;
        filestr.open (ss.str().c_str(), fstream::in | fstream::out | fstream::app);
        filestr << word.c_str() << endl;
    }


    return 0;
}

---

you wouldn't be able to leave out the .close(). You declare the fstream object outside the loop, and so it isn't destructed for each loop iteration. And calling .open() again doesn't automatically close the file, as this page indicates:

Quote:

---

If the object already has a file associated (open), the [open()] function fails.

---

Your code is fine as is, but if you wanted to take advantage of automatic-filestream-closing, you could do this:

Code:

---

int main ()
{
    fstream filestr;
    filestr.open ("test.txt", fstream::in | fstream::out | fstream::app);

    const string filename  = "file";
    const string extension = ".txt";
    stringstream ss;
    string word;

    for (int i = 0; i < 5; ++i)
    {
        cout << "Enter word: "; cin >> word;
        ss << filename << i << extension;
        filestr.open (ss.str().c_str(), fstream::in | fstream::out | fstream::app);
        filestr << word.c_str() << endl;
        filestr.close();
    }


    return 0;
}

---

Since the fstream object is declared inside the loop, it will be destructed when the loop finishes an iteration and begins the next. And it will automatically close itself when this happens. This probably isn't as efficient, execution-speed wise (allocating and freeing the fstream variable), but I doubt that it's a significant speed hit, especially since file I/O is so slow. And it means that you don't have to remember to close the file yourself. :)

dwks, it appears your code examples are backwards.

Thank you Dwks i was wondering how to do it indeed.

Yes i guess the examples mixed up.

BTW, this:

Code:

---

filestr << word.c_str() << endl;

---

should be:

Code:

---

filestr << word << endl;

---

The only weirdness with strings and fstreams is when providing a filename to open. The operator<< and operator>> used with the streams work fine with strings.

Yes i figured that out in the meantime, thanks! :)

And whats the deal with the 'fstream::in' or 'ios::in'.

Its if i use 'fstream filestr;' i should use 'fstream::in',

and if i use 'ofstream' or 'ifstream' i must use 'ios::in'?

Quote:

---

Originally Posted by Ducky

Yes i figured that out in the meantime, thanks! :)

And whats the deal with the 'fstream::in' or 'ios::in'.

Its if i use 'fstream filestr;' i should use 'fstream::in',

and if i use 'ofstream' or 'ifstream' i must use 'ios::in'?

---

There's no difference. fstream is derived (ultimately) from ios_base, and as such you can access the flags by prefixing them with the fsteam class name. In other words, had you derived a class my_ofstream from ofstream you could access the flags as my_ofstream::in, etc.

>> and if i use 'ofstream' or 'ifstream' i must use 'ios::in'?

Most of the time the default values are all you need, so you don't actually have to use all those flags. If you are reading from a file use an ifstream (which defaults to ios::in) and if you're writing to a file use ofstream (which defaults to ios::out). I think you would need ios::app if you're appending to the end of the output file, but otherwise you should be good without those cluttering up the code.

The only thing to really remember is to use std::ios:binary when you are doing read and write if you want code that works on Windows

>> The only thing to really remember is to use std::ios:binary when you are doing read and write if you want code that works on Windows

That doesn't make sense and I'm pretty sure it's not true. I'm not sure why you'd think that.

And if i use fstream i can do both reading and writing to a file?
Or whats good then fstream for?

I dont understand whats happening here, nothing's getting written to the file.

Code:

---

#include <fstream>
#include <iostream>
#include <string>

using namespace std;
ofstream file;

int main () {

    string word;
    file.open ("test.txt", ios::app);
    file << "\nOk";

    while(1){
            cout << "Enter word: "; cin >> word;
            file << word << "\n";
    }

  return 0;
}

---

Quote:

---

Originally Posted by Ducky

And if i use fstream i can do both reading and writing to a file?
Or whats good then fstream for?

I dont understand whats happening here, nothing's getting written to the file.

Code:

---

#include <fstream>
#include <iostream>
#include <string>

using namespace std;
ofstream file;

int main () {

    string word;
    file.open ("test.txt", ios::app);
    file << "\nOk";

    while(1){
            cout << "Enter word: "; cin >> word;
            file << word << "\n";
    }

  return 0;
}

---

---

File I/O is buffered, and if you kill the program (which is the only way this program is going to stop) you may or may not get that buffer written out. Write a program that actually ends, and you may get something you like.

>> And if i use fstream i can do both reading and writing to a file?

Yes, but there are only rare occasions where you actually want to do that with the same fstream variable. Normally, you'd have two separate variables, one for reading and one for writing, since the reading and writing would happen at different points in your program. (For example, you read in your data file at the beginning, then after the user makes changes, you write it out again at the end.)

Thank you Daved, i get it now.

Tabstop:
"File I/O is buffered, and if you kill the program (which is the only way this program is going to stop) you may or may not get that buffer written out."

The same program works with fopen(). Does it mean that fopen() not buffered?

Quote:

---

The same program works with fopen(). Does it mean that fopen() not buffered?

---

Reads and writes are buffered. fopen() is not a read or a write...

I meant the combination fopen() with fputs().

Like ofstream with <<.

Yes, fputs() is buffered. You can flush the buffer to the file by calling fflush(), or you can just close the file with fclose().

You can always flush the fstream stream manually as well (using std::flush or std::endl).

Quote:

---

Originally Posted by Daved

>> The only thing to really remember is to use std::ios:binary when you are doing read and write if you want code that works on Windows

That doesn't make sense and I'm pretty sure it's not true. I'm not sure why you'd think that.

---

Try it out yourself then.

I've done reading and writing on Windows many times in text mode and it has worked just fine.

Were you specifically talking about the read and write functions?

Quote:

---

Originally Posted by Daved

Were you specifically talking about the read and write functions?

---

Yes.

And what is it about Windows that make those functions only work in binary mode that doesn't happen on Linux or other platforms?

Quote:

---

Originally Posted by Daved

And what is it about Windows that make those functions only work in binary mode that doesn't happen on Linux or other platforms?

---

I believe it is the view UNIX has, everything is a file, every file is binary (no such thing as text), thus you automatically get the fstream treated as binary.

Quote:

---

Originally Posted by Tux0r

I believe it is the view UNIX has, everything is a file, every file is binary (no such thing as text), thus you automatically get the fstream treated as binary.

---

You are wrong.

The short answer is that you should use text mode if you are reading/writing text, and use binary mode if you are reading/writing binary data. This should be done regardless of what platform you use.

Now it just so happens that Unix systems don't do any character conversions in text mode, so it doesn't matter if use text or binary mode. It is best to just stick to the above principal though, and not rely on the platforms handling of text.

In this case, the poster is dealing with text, so the file should be opened in text mode.

Quote:

---

Originally Posted by bithub

You are wrong.

*captain obvious removed*

Now it just so happens that Unix systems don't do any character conversions in text mode, so it doesn't matter if use text or binary mode. It is best to just stick to the above principal though, and not rely on the platforms handling of text.

In this case, the poster is dealing with text, so the file should be opened in text mode.

---

lol, you say I am wrong then you state what I just said?

Quote:

---

Originally Posted by Tux0r

lol, you say I am wrong then you state what I just said?

---

You stated:

Quote:

---

Originally Posted by Tux0r

The only thing to really remember is to use std::ios:binary when you are doing read and write if you want code that works on Windows

---

Granted, bithub did not quote that, but the principle (or perhaps rule of thumb) that bithub proposed is in contradiction to the one that you proposed.

Quote:

---

The only thing to really remember is to use std::ios:binary when you are doing read and write if you want code that works on Windows

---

This is wrong. He is using text, he should not be using binary mode to read and write. My post was to clarify this.

Quote:

---

every file is binary (no such thing as text),

---

This is wrong. Every file in unix is not binary. There are plenty of text files (look at everything in the /etc directory). Just because Unix does not perform text conversion does not mean there is "no such thing as text".

I fail to see how I stated what you said. You said "use binary". I said "use text". Those seem to be the opposite...

Quote:

---

Originally Posted by bithub

This is wrong. He is using text, he should not be using binary mode to read and write. My post was to clarify this.

This is wrong. Every file in unix is not binary. There are plenty of text files (look at everything in the /etc directory). Just because Unix does not perform text conversion does not mean there is "no such thing as text".

I fail to see how I stated what you said. You said "use binary". I said "use text". Those seem to be the opposite...

---

I don't see why to argue about this but oh well. I was just giving OP an advice that is not directly related to the original question (remember to use std::ios::binary when using read and write if you want windows compatibility). And so:

>> Now it just so happens that Unix systems don't do any character conversions in text mode, so it doesn't matter if use text or binary mode. It is best to just stick to the above principal though, and not rely on the platforms handling of text.

is just restating what I said about it being vague on UNIX. I don't see why you said I was wrong and then came to the conclusion that I came to as well (marked bold).


also http://en.wikipedia.org/wiki/Binary_file#Manipulation