std::endl vs cout '\n'

Dlaczego w książkach, tutorialach wszędzie używają std::endl zamiast \n? Jakie korzyści ma używanie std::endl w porównaniu z dodaniem na końcu stringa w cout \n?

https://stackoverflow.com/questions/213907/stdendl-vs-n

Czyli można w zasadzie śmiało używać \n w cout i porzucić używanie endla

Źródło:

In many implementations, standard output is line-buffered, and writing '\n' causes a flush anyway, unless std::ios::sync_with_stdio(false) was executed.

https://en.cppreference.com/w/cpp/io/manip/endl

Wrzucam bo może komuś się przyda to w trakcie nauki

Zależy. Jak np. wiesz, że w następnej linii wydarzy się jakaś tragedia (np. proces umrze) to spłukanie bufora ma sens, bo bez tego taki przykładowy log message nigdy się nie wypisze. Miałem taką historię kiedyś tam w pracy

Wydaje mi się, że std::endl to nie jest sztywne wypisanie znaku \n, tylko jest to wypisanie znaku końca linii właściwego dla danego systemu operacyjnego. W większości przypadków będzie to oczywiście \n, ale w Windows będzie to \r\n.

@andrzejlisek

Nie, \n jest tłumaczony na odpowiednią sekwencję. Różnica między std::endl i \n to (tak jak podlinkował @slsy) gwarantowany fflush.

https://en.wikipedia.org/wiki/Newline

The C language provides the escape sequences \n (newline) and \r (carriage return). However, these are not required to be equivalent to the ASCII LF and CR control characters. The C standard only guarantees two traits:

• Each of these escape sequences maps to a unique implementation-defined number that can be stored in one char value.
• When writing to a file, device node, or socket/fifo in text mode, \n is transparently translated to the native newline sequence used by the system, which may be longer than one character. When reading in text mode, the native newline sequence is translated back to \n. In binary mode, no translation is performed, and the internal representation produced by \n is output directly.

teraz jest std::print i on nie wymuszonego flush, i chyba lepiej to dizś używać jak std::cout może? NAwet turner coś nagrywał

Czyli można w zasadzie śmiało używać \n w cout i porzucić używanie endla

Generalnie w większości przypadków to tak. Z tymże są skrajne sytuacje o których wspominał @slsy więc o różnicy jednak warto pamiętać.

Taki drobny przykład do zilustrowania różnicy.

#include <iostream>
#include <unistd.h>

int main()
{
  for (int a=0; a<5; ++a)
  {
    std::cout << "Hello " << a << std::endl;
    sleep(1);
  }
  for (int a=0; a<5; ++a)
  {
    std::cout << "Hello " << a << '\n';
    sleep(1);
  }
}

Program uruchamiamy z terminala - \n i endl zachowują się tak samo, czyli co sekundę widzimy nowy komunikat.

ALE... stdout jest line-buffered tylko jeśli jest skojarzony z terminalem, zatem wystarczy przesłać wynik działania przez pipe do innego programu i efekt jest taki:

$ ./a.out | ts -s
00:00:00 Hello 0
00:00:01 Hello 1
00:00:02 Hello 2
00:00:03 Hello 3
00:00:04 Hello 4
00:00:10 Hello 0
00:00:10 Hello 1
00:00:10 Hello 2
00:00:10 Hello 3
00:00:10 Hello 4

Z tego co kojarze to std::endl to jest \n + std::flush, czyli czyści bufor.

W praktyce raczej nie spotkasz się z przypadkiem, że coś się wywali przez to, więc służy to tylko do testowania innych programistów w firmie. Jak się czepiają to są zyebami. Jak nie, to spoko zespół.

Zamiast zgadywać/kojarzyć, nie prościej zerknąć do kodu źródłowego?

  // Standard basic_ostream manipulators

  /**
   *  @brief  Write a newline and flush the stream.
   *
   *  This manipulator is often mistakenly used when a simple newline is
   *  desired, leading to poor buffering performance.  See
   *  https://gcc.gnu.org/onlinedocs/libstdc++/manual/streambufs.html#io.streambuf.buffering
   *  for more on this subject.
  */
  template<typename _CharT, typename _Traits>
    inline basic_ostream<_CharT, _Traits>&
    endl(basic_ostream<_CharT, _Traits>& __os)
    { return flush(__os.put(__os.widen('\n'))); }

WeiXiao napisał(a):

Zamiast zgadywać/kojarzyć, nie prościej zerknąć do kodu źródłowego?

Kopiuj

   *  This manipulator is often mistakenly used when a simple newline is
   *  desired, leading to poor buffering performance.  See

Jeśli nie wypluwasz megabajtów na standardowe wyjście to nie ma się czym przejmować. A jeśli wypluwasz to… trzeba rozważyć, co jest ważniejsze.