using getline to grab 2 seperate arrays

I have a txt file that looks like
blah
324342
blah
23423
blah
23423232
ect..

And I am trying to use getline to grab the seperate lines and assign them to the correct arrays but when I do I keep getting an error, I must be doing something wrong.

• Use a while loop with eof to read a title and an income and assign them to title[] and income[] respectively. x is a counter for the number read.

I'll eventually have to sort and search the arrays with functions but I just need to figure out how to assign them for now.
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
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
 include<iostream>
#include<iomanip>
#include<cstdlib>
#include<fstream>
#include<cmath>
#include<string>

using namespace std;


//constant
const int MAX = 100;


//prototypes


int main()
{
	//variables
	ifstream inMovie;
	ofstream outMovie;
	string title[MAX];
	int income[MAX];
	int quantity = 0;
	int x = 0;
	long sum = 0;
	double avg;

	//input
	inMovie.open("TopMovies.txt");
	outMovie.open("TheBest.txt");
	if (inMovie.fail())  //closes file incase the file is wrong
	{
		cout << "I didn't find your file.  I will close now. \n";
		exit(1);
	}
	while (!inMovie.eof()) //getting input from a file
	{
		getline(inMovie, title[x]);
		getline(inMovie, income[x]);
		x++;

	}
	
	
	//calculations
	




	//output

	inMovie.close();
	outMovie.close();

	return 0;
}
Last edited on
For starters getline() only works with strings.

You really need to start learning how to interpret your compiler messages.

Lastly using eof() to control a read loop will usually end up giving you one "extra" data point, you should use the actual read to control the loop.



I have to use the eof() and lets say I change it to

1
2
3
4
5
6
while (!inMovie.eof()) //getting input from a file
	{
		getline(inMovie, title[x]);
		inMovie >> income[x];
		x++;
	}
Use a while loop with eof to read

The use of eof() is not appropriate here. Bad instructions.

It would be polite to show the error. Was it this?
41:29: error: no matching function for call to 'getline(std::ifstream&, int&)'

Getline reads line of text, not integers.

You can either read integer and handle the newline, or read line first and then conver it to integer. This is the latter:
1
2
3
4
5
6
7
8
9
10
11
12
13
if ( !inMovie ) {
  cout << "I didn't find your file.  I will close now. \n";
  return 1; // no need to exit()
}

string name;
string number;
while ( getline(inMovie, name) && getline(inMovie, number) ) {
  // IF and only IF we did successfully read two lines
  title[x] = name;
  income[x] = std::stoi( number ); // http://www.cplusplus.com/reference/string/stoi/
  x++;
}
I decided to use the conversion I didn't know you could do string to integer so that is cool.
Thanks for the help it is working now.
If you are instructed to use .eof() you should reconsider the quality of your instruction. Using EOF has always been wrong.

The most correct (and simplest to understand, IMHO) way to look at it is:

1
2
3
4
5
6
7
8
9
10
11
12
while (true)
{
  // try to get input
  getline( cin, s );

  // did the attempt fail?
  // if so, break the loop
  if (!cin) break;

  // otherwise, all is good. play with your input
  do_something( s );
}

C++ is designed to make that kind of thing really pretty, because getline() returns the argument stream, which can then be automagically tested for goodness in a while/for/if/whatever condition:

1
2
3
4
5
while (getline( cin, s ))
{
  // If I get this far, then input was good
  do_something( s );
}


When you loop on EOF, you process even the bad inputs, because the test for goodness only occurs at the beginning of each loop, instead of immediately after an attempt to obtain input like it should:

1
2
3
4
5
6
7
8
9
10
while (!f.eof())  // BAD! BAD! BAD! BAD! BAD!
{
  // attempt to get input
  getline( f, s );

  // even if input was bad, here we go...
  do_something( s );

  // time to loop and test whether or last attempt at input was good
}

Likewise, testing for EOF has another pitfall: it only tests for EOF. If your input was bad in some other way (say, you tried to read an int but the input was "ABC"), then you have just created an infinite loop, since .eof() will never return true.

Hope this helps.
Maybe the 'diplomatic' solution is to submit both ways of doing it and demonstrate why testing for eof() is bad.

Nobody is suggesting it here but confronting or openly defying an instructors dogma is often a bad move, especially if they are the marker.
againtry wrote:
Maybe the 'diplomatic' solution is to submit both ways of doing it and demonstrate why testing for eof() is bad.

Nobody is suggesting it here but confronting or openly defying an instructors dogma is often a bad move, especially if they are the marker.

Agreed. I wouldn’t bother to confront the professor with the problems with and EOF loop. They have been well known since the ’60s.

I mention it so that the OP recognizes the very real problem with this astoundingly common bad idiom.
Last edited on
To be clear it was an adjunct, and not any sort of counter to your sound advice.

As we all know when a markers ego is at stake, the outcome might be inspired more by pr-history chimp-behavior rather than modern intellectual academic honesty.

If the academic bucks about it and issues forth then there is at least a paper trail for the appeal or court case if it needs to go that far.
Usually it is just because the professor does not know the modern language.

University CS professors are often experts in a different field or technicality, and are asked as part of their position to teach basic C++ or Java or something. They have to then dig up their old course materials and/or whatever they can find online to learn the basics, and as often as not it is out of date.

As long as they get to continue their university-sponsored studies of something like “finite automata in AI recognition support systems for robotic force-sensitive decision trees when handling hard and soft objects” or something like that... being bothered to teach a computer language they don’t use is not that much to be asked.
Topic archived. No new replies allowed.