Output Error!

[lkegley]

PLEASE HELP!!!

This is the method I had written for a game data program I'm working on. OpponentName and HomeScore are private variables in game.cpp (the code below is from team.cpp) and I know I probably shouldn't use them here; instead, should I use a get method? And how do I output that information? I need this method to be able to return the maximum score and the opponent's name during this game from a data file that has a list of all the opponent names, home scores, and opponent scores for the season.



string Team::MaxHomeScore(const string Maximum, const string Filename)
{
ifstream Din;
Din.open(Filename.c_str());

if(!Din)
{
cerr << "Error: That file could not be opened!";
}
else
{
Din >> TeamName >> Season;

while(Games[NumGames].ReadGameData(Din))
{
for(NumGames = 0; NumGames < MAXGAMES; NumGames++)
{
if (Games[NumGames] > Maximum)
{
Maximum = Games[NumGames];
}
}

cout << OpponentName << " " << HomeScore << endl;
}
}

return Maximum;

[gcampton]

setters and getters simply make private variables hidden so instead of declaring them public and allowing other classes to use them as this is bad concept.


so say for instance we have declared int number; as private.

private:
   int number;
};

void class::setNumber(int num)
{
   number = num;
}
int class::getNumber()
{
   return number;
}

so in this design to set the variable of number you use the setNumber(number_we_want_to_set);
and to get the value of number, getNumber();

[helios]

Yes, that makes perfect sense. Do you mind if I ask how what you have up there is different from making number public, other than being slower?

[lkegley]

I'm still really stuck on what I should do in this method.

[Disch]

@ helios:

It depends on what the class does, really. If 'number' could have an impact on other variables or another state of the class, then it's best to have it in a set/get system rather than having direct access so the state changes can be made.

Say for example you have a class which represents a Line. It has two points, A and B. It might make sense to have A and B be public members. But what if you want it to do something else, like keep track of the length of the line?

class Line
{
public:
  void SetA(const Point& a){ A = a; MakeDirty(); }
  void SetB(const Point& b){ B = b; MakeDirty(); }

  Point GetA() const { return A; }
  Point GetB() const { return B; }

  double GetLength()
  {
    if( IsDirty() )
    {
      Point c(A - B);
      length = sqrt( (c.x * c.x) + (c.y * c.y) );
      MakeClean();
    }
    return length;
  }
private:
  Point A, B;
  double length;

 // dirty stuff here
};

This approach means the length is only recalculated when needed. Of course this isn't necessary (and there's an argument for why it's not a good idea -- const correctness comes to mind immediately), but this is just an example of why you'd want something like this.

Also, if the functions are inlined they're not slower.

Even if you don't have need for a get/set interface right away... you may change the class to require one in the future. And if you have the members public, this means you have to change the entire interface for the class and rewrite all of your code that uses the class (could be a big job), so there's a argument for putting in Get/Set functions in from the get-go.


ALL OF THAT SAID:

I agree with you that it probably isn't necessary in this case. And while I list the rationale for the get/set approach above, I don't believe that you should always put get/set functions everywhere. A lot of the time, you're really better off with public members. I don't agree with gcampton that having public members is "bad concept". I think needlessly making a million get/set functions for every property is a bad concept.

But it really does depend on the situation. This is one of those things where there is no "one size fits all" solution. Use what's best for the task at hand.

[gcampton]

Yes, that makes perfect sense. Do you mind if I ask how what you have up there is different from making number public, other than being slower?

By slower do you mean coding wise? or compiling? or execution?

I doubt it would make too much difference on compiling, however you would see expodential growth on large apps, for execution I don't think this would make any difference. And for coding, it's not really that bid of a deal.

I guess it's coders choice, really depends if you want or need to hide variables from other classes / coders / team members. Because when it comes down to it it's pretty much the only function of it is to hide data from being manipulated in ways we don't want. So I think my original comment of "allowing other classes to use them as this is bad concept." is more than incorrect. But at the same time I was mostly preaching java philosophies, as this is seriously drilled in, in java programming. Not so much in C++ from what I have seen.

[helios]

for execution I don't think this would make any difference

I'd guesstimate it's ten times slower than direct assignment, without inlining. Considering it's something that doesn't need to exist, that's pretty expensive.