XPost: alt.comp.lang.c++.misc

This is amazing. printf() takes priority in this simple program:


#include <iostream>

using namespace std;

int main(void)
{
int something;
ios_base::sync_with_stdio(false);
cin.tie(NULL);



for (int i = 0; i< 10; i++)
{
cout << "using cout here\n";
printf("using printf here\n");
}

printf("Enter a number here: ");
cin >> something;
}

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Fri, 29 Nov 2024 05:35:54 +0000
schrieb Student Project <student@invalid.invalid>:

This is amazing. printf() takes priority in this simple program:

This is simply due to the fact that cout has not yet been flushed. Use

cout << "using cout here"<<endl;

and it will be flushed before printf is called.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 29 Nov 2024 09:10:08 +0100
Ralf Goertz <me@myprovider.invalid> wibbled:

Am Fri, 29 Nov 2024 05:35:54 +0000
schrieb Student Project <student@invalid.invalid>:

This is amazing. printf() takes priority in this simple program:

This is simply due to the fact that cout has not yet been flushed. Use

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

* Ralf Goertz <me@myprovider.invalid>
| Am Fri, 29 Nov 2024 05:35:54 +0000
| schrieb Student Project <student@invalid.invalid>:

| > This is amazing. printf() takes priority in this simple program:

| This is simply due to the fact that cout has not yet been flushed. Use

| cout << "using cout here"<<endl;

| and it will be flushed before printf is called.

I'd guess this is what

https://en.cppreference.com/w/cpp/io/ios_base/sync_with_stdio

is for...

R'

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 29 Nov 2024 11:25:41 +0100
Bonita Montero <Bonita.Montero@gmail.com> 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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 29 Nov 2024 13:03:01 +0100
Bonita Montero <Bonita.Montero@gmail.com> wibbled:

Am 29.11.2024 um 11:29 schrieb Muttley@DastardlyHQ.org:

On Fri, 29 Nov 2024 11:25:41 +0100
Bonita Montero <Bonita.Montero@gmail.com> 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. ..

I'm talking about cout, not stdout.

Where do you think cout writes to?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 29 Nov 2024 13:12:54 +0100
Bonita Montero <Bonita.Montero@gmail.com> wibbled:

Am 29.11.2024 um 13:04 schrieb Muttley@DastardlyHQ.org:

On Fri, 29 Nov 2024 13:03:01 +0100
Bonita Montero <Bonita.Montero@gmail.com> wibbled:

Am 29.11.2024 um 11:29 schrieb Muttley@DastardlyHQ.org:

On Fri, 29 Nov 2024 11:25:41 +0100
Bonita Montero <Bonita.Montero@gmail.com> 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. ..

I'm talking about cout, not stdout.

Where do you think cout writes to?

The buffering between stdout and cout is not forcfully joined.

I doubt there's 2 stages of buffering, it would be very inefficient.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/29/24 05:29, Muttley@DastardlyHQ.org wrote:

On Fri, 29 Nov 2024 11:25:41 +0100
Bonita Montero <Bonita.Montero@gmail.com> 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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 29 Nov 2024 19:11:51 -0500
James Kuyper <jameskuyper@alumni.caltech.edu> gabbled:

On 11/29/24 05:29, Muttley@DastardlyHQ.org wrote:

On Fri, 29 Nov 2024 11:25:41 +0100
Bonita Montero <Bonita.Montero@gmail.com> 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 prefer looking at what actual implementations do rather than the "official" behaviour. If \n didn't by default do an automatic flush every single printf would need fflush(stdout) following it and cout would need << flush. Clearly that is not the case.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/29/24 21:41, Keith Thompson wrote:

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

...

"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).

You're correct. I should have cut-and-pasted the text to make sure it
matched.
I'm married to a woman whose native language is not English, and who
frequently leaves out small, "unimportant" words like "not" :-(.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)