At the risk of "but that is exactly OP's code!", I would personally favor this version if this is the entire body of a scope (e.g. function that parses the text):
vector<string> Text;
string Line;
while (getline(cin, Line))
Text.push_back(Line);
Alternatively, if part of a larger scope, I would probably group all four lines together and add empty lines before and after for visual coherence (and maybe add a short comment before it):
// [lots of other code]
// Gather input from cin.
vector<string> Text;
string Line;
while (getline(cin, Line))
Text.push_back(Line);
// [lots of other code]
I am aware that this introduces no clever tricks, but this is the most compact and readable form of the given code, at least to me.
If you wanted compactness above all else, you could choose garbage variables, omit all unnecessary whitespace and even alias the types beforehand (since we are "often writing" this kind of code this is a one-off) to, say, V<S> t;S l;while(getline(cin,l))t.push_back(l);
but nobody wants to read that.
So clearly there is more than compactness at play. As for me, I'm looking to keep noise to a minimum while retaining intuitive readability, and I would suggest this is an agreeable goal.
I would never use the "throw everything into the loop condition" suggestions because that very much breaks how I expect code to be structured: The main purpose of your loop goes into the loop body. You may disagree/have different expectations, but in my eyes everything else is just an attempt to show off your minifying skills, it does not produce good code.
The above accomplishes just that: The braces are noise for this simple operation, and the important part stands out as the loop body. "But is getline
not also important?" - It is, and I would honestly prefer a version where it is in the loop body, such as a hypothetical
vector<string> Text;
while (cin.hasLine())
Text.push_back(readLine(cin));
This would be an ideal loop to me: The condition only checks for termination and the loop body is only the operation we want to repeat.
Even better would be a standard algorithm, but I unaware of any that would help here (ranges or boost might provide, I don't know).
On a more abstract level, if OP frequently writes this exact code, it should obviously be a separate function. But even if not, the "lots of other code" example would benefit from that abstraction too.