0

So I'm learning C++ and I'm well aware that I suffer from premature optimization syndrome, but I feel like code is one of the few things in the world that can most practically aim for perfection, so I'm trying to maximize performance and efficiency here as well as develop the absolute best practices.

So there are three ways (I'm currently aware of) to do new lines:

cout << "Hello, World." << endl;
cout << "Hello, World." << "\n";
cout << "Hello, World." << '\n';

Despite that almost every beginner C++ book uses it early on, my own research has shown that endl should be avoided unless you know you have to "clear the buffer." My understanding of what the "buffer" even is is mostly irrelevant at this point.

So that narrows it down to "\n" and '\n' for most cases. I then gathered that "\n" is read as two separate characters and converted to a character. That makes it clear what to use in a situation where a newline is entered after sending a variable to an object like cout:

int age = 25;
cout << "age = " << age << '\n'; // more efficient
cout << "age = " << age << "\n";

My main question - which is the better case when you end the statement with a string?

int age = 25;
cout << "I am " << age << " years old.\n";
cout << "I am " << age << " years old." << '\n';

One includes the \n escape character in the string, but includes an extra character. The other has the single '\n' character but requires an extra << operator. Is there any way to measure which one is ultimately better? I realize I'm splitting hairs here, but I don't have the personality that allows me to get over these simple things without answers.

In a program with perhaps thousands of these types of lines, I'd like to save that fraction of CPU time if it exists. Thanks.

  • 2
    '\n' is a character and "\n" is string. – rajuGT Nov 09 '15 at 17:50
  • 3
    "I'm trying to maximize performance and efficiency here as well as develop the absolute best practices" -- unfortunately these are not always compatible - you should prioritise best practices (readability, robustness, portability, etc) over performance/efficiency. – Paul R Nov 09 '15 at 17:53
  • 1
    Just use "\n". For consistency. – Emil Laine Nov 09 '15 at 17:55
  • Looks like I got some good answers below. I don't want to overload the << operator since it's basically calling another function. I'll also be sure not to ask questions before I have a better understanding of the language since this is apparently getting downvoted. – Dustin Trombly Nov 09 '15 at 17:57
  • Your question is fine. Don't worry about a down vote or 2. Also, if an answer was satisfactory, please accept it. – Anon Mail Nov 09 '15 at 18:20
  • 1
    You are dealing with input/output. I/O is slooooooooooooooow. You want to save that fraction of CPU time so that the slowness of the rest of the system is more evident? This is not even *premature* optimization, this is *useless* optimization. No offense, don't get me wrong. I just want to make sure you realize that even writing a test capable of showing the difference is close to impossible. And noticing the difference in a real case *is* impossible. – Fabio says Reinstate Monica Nov 09 '15 at 18:26
  • Before even understanding how the small the hairs were that I was splitting, I was pretty aware that this is virtually useless. That doesn't stop my obsessive mind from focusing on them. :/ – Dustin Trombly Nov 09 '15 at 18:28
  • 1
    I would love to see you try and measure the difference! So basically the only slowness you will see is the time it takes to type it and the time it takes for people to read it. Given the double take people will do seeing `'\n'` It will use up 400 milli seconds per person (lets say your code is stable and it is only reviewed three times in 10 years). Thats a total of 1,200 milli seconds wasted. I bet in the same time frame, ten years, you will not regain that time in performance improvements between the two versions in running code. – Martin York Nov 09 '15 at 20:44
  • @FabioTurati I/O is not necessarily slow. It might be memory-mapped I/O. Or, perhaps, instead of cout, you might be using something like a ostringstream. I realise we've already spent more time talking about this than the whole world will ever save by using '\n' instead of "\n", but for the sake of satisfying the OP's obsession, when everything else is equal - in other words, '\n' and "\n" have equal readability and maintainability - and there is nothing else to choose between them, then go for efficiency - even if it's nanoseconds. Except when the "\n" is already part of a preceding string. – Klitos Kyriacou Nov 09 '15 at 20:49
  • @KlitosKyriacou you are right, in those cases I/O isn't slow, I was only thinking of the most obvious use case. But there's another thing to consider: compiler optimizations. Honestly I know nothing of Assembly and I can't check myself, but I wouldn't be surprised if it turned out that a decent compiler generates exactly the same code. And I'm not even talking about -O3. That said, I just wanted to warn Dustin that the improvement can't be noticed. He says he's aware of it but he still wants to know the answer: I have no problem with that. – Fabio says Reinstate Monica Nov 10 '15 at 00:05

2 Answers2

2

If you think that

cout << "I am " << age << " years old." << '\n';

may be better, then why stop there? By extension, this would in turn be better:

cout << "I am " << age << " years old" << '.' << '\n';

and so on...

cout << "I am " << age << " years ol" << 'd' << '.' << '\n'; // etc...

Just stick to the original pure string.

Klitos Kyriacou
  • 10,634
  • 2
  • 38
  • 70
  • This does not answer to the question. OP said nothing about dividing the string, it's about printing newline, which is usually not part of the string itself. – Mateusz Grzejek Nov 09 '15 at 18:12
  • 3
    @MateuszGrzejek the question specifically mentions whether instead of `cout << "some string\n"` you should instead do `cout << "some string" << '\n'` so I used a "Reductio ad absurdum" technique to answer it. – Klitos Kyriacou Nov 09 '15 at 18:14
  • To give a complete answer, if the newline is at the end of a literal string, as in the final part of the question, I make it part of the string. If it's on its own (or after a variable) then in terms of readability "\n" and '\n' are about the same so I choose '\n' because it's "simpler". – Klitos Kyriacou Nov 09 '15 at 20:44
1

You should use the first. The second requires an extra function call. What's more, I think it's also more natural typing wise.

Anon Mail
  • 4,660
  • 1
  • 18
  • 21