getline issue for opening files

I am trying to write a very simple program that writes text to a file, and i have searched everywhere and i can find an answer to my problem, so i am confused. This is the program...

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

int main() {
char filename[81];

cout << "Enter a file name and press ENTER: ";
cin.getline(filename, 80);
ofstream file_out(filename);
if (! file_out) {
cout << "File " << filename << " could not be opened.";
return -1;
}

cout << "File " << filename << " was opened." << endl;
while (1) {
cout << "Enter line (@@@ to quit)>>";
cin.getline(input_line, 80);
if (strcmp(input_line, "@@@") == 0)
break;
file_out << input_line << endl;
}
file_out.close();
return 0;
}

Everytime i use this it keeps telling me that the file could not be opened (I made sure the file is there), but when i use " cin >> filename;" instead of "cin.getline(filename);" it works. For the sake of consistency I would rather use the getline, and i know it should work. What could be wrong?

Im using eclipse in Windows XP64. Don't know if that matters
Last edited on
Only a couple of modifications:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
#include <iostream>
#include <fstream>
#include <cstring>  // for strcmp()
using namespace std;

int main() {
  char filename[80];
  char input_line[80];  // don't forget to declare stuff you use

  cout << "Enter a file name and press ENTER: ";
  cin.getline(filename, 80);  // reads n-1 characters, so max 79 characters read +1 for '\0'

  ofstream file_out(filename);
  if (! file_out) {
    cout << "File " << filename << " could not be opened.";
    return 1;  // don't return negative numbers -- keep them positive and between 0 and 255
    }

  cout << "File " << filename << " was opened." << endl;
  while (1) {
    cout << "Enter line (@@@ to quit)>>";
    cin.getline(input_line, 80);
    if (strcmp(input_line, "@@@") == 0)
      break;
    file_out << input_line << endl;
    }

  file_out.close();
  return 0;
  }

Your code works fine for me.

How are you running your program? Is it from the IDE, or are you running it directly from the command prompt? Are you sure you have write permission on the current working directory?

(If you want to check the current working directory, you can use this function:
1
2
3
4
5
6
7
8
#include <string>
#include <unistd.h>

std::string getcwd()
  {
  char result[ 1024 ];
  return std::string( getcwd( result, sizeof( result ) ) );
  }
And use it thus:
1
2
3
  cout << "The current working directory is "
       << getcwd()
       << endl;


Hope this helps.
don't return negative numbers [from main] -- keep them positive and between 0 and 255

Why is that?
POSIX compatibility. The way the OS uses main()'s return code is "implementation defined" with the sole exception that a value of zero is considered to be the same as the implementation's normal successful exit code. In practice, systems that actually do return an exit code from programs follow the POSIX tradition, where exit codes are (N & 0xFF). This includes DOS and Windows. (Windows allows a 32-bit unsigned value... but I'm not sure even the command processor can use that big a value...)

Return values are really outside the language specification and in practice fall into the domain of "common practice" -- which is: use zero for success and non-zero for error. However, the actual meaning of those values depend on your environment. (I once wrote a nice test program to be used in DOS batch scripts, since DOS's if command is wimpy. The return codes were very specifically specified for that program as successful execution was always assumed.)

In any case, on systems that maintain application exit codes, the range 0..255 is the common ground.
http://linux.die.net/man/3/exit
http://linux.die.net/man/2/wait

Hope this helps.
This is annoying. Every time I see a question I can actually answer, it's already been answered >:(

Next time an English person posts a question, and isn't me, I'll have an advantage. You guys will all be asleep. HAHAHAHA.
Topic archived. No new replies allowed.