Path: csiph.com!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c++ Subject: Re: printf() takes priority here!!! Date: Fri, 29 Nov 2024 18:41:14 -0800 Organization: None to speak of Lines: 47 Message-ID: <87plmdqw8l.fsf@nosuchdomain.example.com> References: MIME-Version: 1.0 Content-Type: text/plain Injection-Date: Sat, 30 Nov 2024 03:41:15 +0100 (CET) Injection-Info: dont-email.me; posting-host="d28f02e76a6c2d00a69abdf93e7df1d2"; logging-data="1428244"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1++LqK/9pfIHYZa8AHgaFTm" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:Cuv/PMyBFLrd8xXpxP8m8J4ss4w= sha1:zEDctbrs1HbHF1+DGm8MnrTKnO8= Xref: csiph.com comp.lang.c++:121090 James Kuyper writes: > On 11/29/24 05:29, Muttley@DastardlyHQ.org wrote: >> On Fri, 29 Nov 2024 11:25:41 +0100 >> Bonita Montero wibbled: >>> Am 29.11.2024 um 11:13 schrieb Muttley@DastardlyHQ.org: >>> >>>> It works as expected on MacOS. The newline should automatically flush cout >>>> stdout just as it does in printf regardless of whether the C and C++ streams >>>> are linked. >>> >>> std::endl guarantees a flush, but not \n. >>> I use that often to have buffering of multiple lines. >> >> I've never seen \n NOT flush stdout. Perhaps things are different in a Windows >> console. Possibly there's some glibc option that may change it on linux and >> similar on Mac but by default it flushes. > > The C++ standard defines cout as managing the stdout stream. All other > statements in the C++ standard about stdout merely cross-reference the > definition in the C standard, without saying anything C++ specific about > it. The C standard associates it with the standard output stream, about > which it says: > > "As initially opened, ... the standard input and standard output streams > are fully buffered if and only if the stream can be determined not to > refer to an interactive device." > > So stdout should be fully buffered, not line buffered, if it can be > determined to refer to an interactive device (such as a computer > terminal). In that case, '\n" should not, in itself, trigger a flush. I think you missed a "not" (unless I missed something myself). If the standard output stream can be determined to refer to an interactive device, it's *not* fully buffered. It can be either unbuffered or line buffered, at least as far as ISO C is concerned. The "can be determined" allows some wiggle room if the implementation can't tell whether the stream refers to an interactive device. A C stream can be unbuffered (characters appear as soon as possible), fully buffered (characters appear when a buffer is filled), or line buffered (characters appear when a new-line character is encountered). -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com void Void(void) { Void(); } /* The recursive call of the void */