Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #121069 > unrolled thread

printf() takes priority here!!!

Back to article view | Back to comp.lang.c++

Contents

  printf() takes priority here!!! Student Project <student@invalid.invalid> - 2024-11-29 05:35 +0000
    Re: printf() takes priority here!!! Ralf Goertz <me@myprovider.invalid> - 2024-11-29 09:10 +0100
      Re: printf() takes priority here!!! Ralf Fassel <ralfixx@gmx.de> - 2024-11-29 10:54 +0100
      Re: printf() takes priority here!!! Muttley@DastardlyHQ.org - 2024-11-29 10:13 +0000
        Re: printf() takes priority here!!! Bonita Montero <Bonita.Montero@gmail.com> - 2024-11-29 11:25 +0100
          Re: printf() takes priority here!!! Muttley@DastardlyHQ.org - 2024-11-29 10:29 +0000
            Re: printf() takes priority here!!! Bonita Montero <Bonita.Montero@gmail.com> - 2024-11-29 13:03 +0100
              Re: printf() takes priority here!!! Muttley@DastardlyHQ.org - 2024-11-29 12:04 +0000
                Re: printf() takes priority here!!! Bonita Montero <Bonita.Montero@gmail.com> - 2024-11-29 13:12 +0100
                  Re: printf() takes priority here!!! Muttley@DastardlyHQ.org - 2024-11-29 12:48 +0000
                    Re: printf() takes priority here!!! Bonita Montero <Bonita.Montero@gmail.com> - 2024-11-29 13:56 +0100
            Re: printf() takes priority here!!! James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-11-29 19:11 -0500
              Re: printf() takes priority here!!! wij <wyniijj5@gmail.com> - 2024-11-30 09:12 +0800
              Re: printf() takes priority here!!! Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-11-29 18:41 -0800
                Re: printf() takes priority here!!! James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-11-30 10:22 -0500
              Re: printf() takes priority here!!! Muttley@dastardlyhq.com - 2024-11-30 10:06 +0000

#121069 — printf() takes priority here!!!

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;
}

[toc] | [next] | [standalone]

#121073

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.

[toc] | [prev] | [next] | [standalone]

#121075

* 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'

[toc] | [prev] | [next] | [standalone]

#121076

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.

[toc] | [prev] | [next] | [standalone]

#121077

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.

[toc] | [prev] | [next] | [standalone]

#121078

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.

[toc] | [prev] | [next] | [standalone]

#121079

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.

[toc] | [prev] | [next] | [standalone]

#121080

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?

[toc] | [prev] | [next] | [standalone]

#121081

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.

[toc] | [prev] | [next] | [standalone]

#121082

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.

[toc] | [prev] | [next] | [standalone]

#121083

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

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

The default is that the streams are synchronized.
But if you turn it off the buffering of both facilities is separate.
The buffering isn't concatenated into stages but just parallel.

[toc] | [prev] | [next] | [standalone]

#121088

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.

[toc] | [prev] | [next] | [standalone]

#121089

On Fri, 2024-11-29 at 19:11 -0500, James Kuyper wrote:
> 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.

So, what the OP reports (output is irregular) is standard conforming?

[toc] | [prev] | [next] | [standalone]

#121090

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> 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 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 */

[toc] | [prev] | [next] | [standalone]

#121094

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" :-(.

[toc] | [prev] | [next] | [standalone]

#121091

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.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c++

csiph-web