Passing cin input to a function

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
#include <string>
#include <iostream>

using namespace std;


class days
{
private:
	string starttime;
public:
	void PutStartTime(string& str)
	{
		starttime = str;
	}

};
int main()
{
	days Day1;
	string strinput;
	getline(cin, strinput);
	Day1.PutStartTime(strinput);
        return 0;
}



Is there a way to pass the cin input directly to the Day1.PutStartTime function, thus combing lines 22 and 23 and making the strinput variable unnecessary?
How about like this? (warning: breaks encapsulation)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
class days
{
private:
   string starttime;

public:
   string& GetReferenceToStartTime()
   {
      return starttime;
   }
};

int main()
{
   days Day1;
   getline(cin, Day1.GetReferenceToStartTime());

   return 0;
}


Unless you're running out of stack space or something, it's probably better to use the "unwanted" variable anyway.
Last edited on
I was just trying to make it as efficient as possible and figured there was an easy way to do it that I just didn't know about. What do you mean by encapsulation?
1
2
3
4
5
6
7
8
9
10
11
class days
{
private:
   string starttime;

public:
   string& GetReferenceToStartTime()
   {
      return starttime;
   }
};


why not just make it public?

1
2
3
4
5
class days
{
public:
   string starttime;
};


thats does the same , right?
You can overload operator>> so that you can read days from cin like you do with other types. If you do this we have to make operator>> a friend of days so that we can access the private members of days in operator>>.

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
#include <string>
#include <iostream>

using namespace std;

class days
{
private:
	string starttime;
public:
	friend istream& operator>>(istream&, days&);
};

istream& operator>>(istream& in, days& d)
{
	getline(in, d.starttime);
	return in;
}

int main()
{
	days Day1;
	cin >> Day1;
	return 0;
}


EDIT: Maybe this was too complicated. You can pass cin to a normal member function if the parameter type is istream&.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
#include <string>
#include <iostream>

using namespace std;

class days
{
private:
	string starttime;
public:
	void readStartTime(istream& in);
};

void days::readStartTime(istream& in)
{
	getline(in, starttime);
}

int main()
{
	days Day1;
	Day1.readStartTime(cin);
	return 0;
}
Last edited on
why not just make it public?


That's an excellent question. Can anybody give me a reason not to make it public? I ask because the book I'm reading to learn C++ indicates that it's best practice to keep your class members private because it's "safer", but it doesn't elaborate.
why not just make it public?


I ask because the book I'm reading to learn C++ indicates that it's best practice to keep your class members private because it's "safer", but it doesn't elaborate.


The book is right, because if you make everything public it is just like having global variables.

In C++, It is best to make all your member variables private or protected, then provide public functions to set and get the member variables.

Here's a somewhat complex example:

Say you want to have the ability to create an arc object by sending it 3 2d points. The 3 points are the beginning of the arc, a point on the arc, and an end point; we might name them A, B, C. Quick geometry lesson: Draw lines AB and BC. The perpendicular Bisectors of these intersect at the center of the arc.

To do these calcs you might need local variable like ABDist, ABBisectorAngle etc.

Now if I was to give you an arc object, you would probably be only interested in: CenterPoint, Radius, StartPoint, EndPoint, say (there are lots of other variations).

So you make everything private or protected, then provide public functions that return only the things that you want. i.e getCenterPoint, getRadius, getStartPoint, getEndPoint.

With set functions, it's the same, and in this case, if you change one thing, you have to recalc all the others.

If everything was public, then changing the CenterPoint would invalidate the others.

Private means that only that class has access to the variables via the code in the member functions, and not via the dot operator. They are inherited, but there won't be access to them in derived classes

Protected means that derived classes also have access to the base's private members via the code in the member functions, and not via the dot operator.

Hope this helps
If everything was public, then changing the CenterPoint would invalidate the others.

Ok, that makes sense. Thanks for clearing that up.
Topic archived. No new replies allowed.