In the past, the following program would throw a ConvException *after* sending the second message to stdout. Now the second message is not displayed at all. Wait! I just checked: The output is actually flushed but after the exception output.

import std.stdio;

void main() {
    int a;
    write("Please enter an int: ");
    readf("%s", &a);

    int b;
    write("Please enter another int: ");
    readf("%s", &b);
}

(That is an example to demonstrate the need and usefulness of the space character in input format specifiers: Replace "%s" with " %s" and the program will work without error.)

I think the current behavior is confusing because the readf error is printed *before* stdout is flushed. That's my understanding anyway...

Thank you,
Ali

On Thursday, 17 February 2022 at 00:13:24 UTC, Ali Çehreli wrote:
> In the past, the following program would throw a ConvException *after* sending the second message to stdout. Now the second message is not displayed at all. Wait! I just checked: The output is actually flushed but after the exception output.

the default is to flush on the newline.... (unless it is a pipe, which happens with a lot of IDEs, in which case it flushes on a buffer size threshold).

since you have no newline here im pretty sure this is the same as how it always worked..... i think.

On 2/16/22 4:17 PM, Adam Ruppe wrote:
> On Thursday, 17 February 2022 at 00:13:24 UTC, Ali Çehreli wrote:
>> In the past, the following program would throw a ConvException *after* sending the second message to stdout. Now the second message is not displayed at all. Wait! I just checked: The output is actually flushed but after the exception output.
> 
> the default is to flush on the newline.... (unless it is a pipe, which happens with a lot of IDEs, in which case it flushes on a buffer size threshold).
> 
> since you have no newline here im pretty sure this is the same as how it always worked..... i think.

I know but the other rule is that reading from stdin flushes stdout automatically. At least I've been assuming that there is such a link between those streams. :)

My current assumption is that somebody changed the order of stderr vs. stdout. That's why the output is more confusing to me now. Just a guess...

Ali

On 2/16/22 16:21, Ali Çehreli wrote:

> the other rule is that reading from stdin flushes stdout
> automatically.

Now I'm in doubt. That's ancient knowledge (belief) for me from C and C++ days. I swear there was a feature where you could link (or lock, or connect?) an output stream to an input stream and reading from the input stream would automatically flush the output stream.

And I've been under the impression that stdin and stdout were such streams. But the internet does not agree with me. Was I dreaming? Was that a special thing about C++'s cout and cin?

Help! Losing my mind...

Ali

P.S. Regardless, an automatic flush feature would be nice between stdin and stdout. But I wouldn't want that unless it "is a tty". Hm... I think I see now.

On Thursday, 17 February 2022 at 00:36:30 UTC, Ali Çehreli wrote:
> On 2/16/22 16:21, Ali Çehreli wrote:
>
> > the other rule is that reading from stdin flushes stdout
> > automatically.
>
> Now I'm in doubt. That's ancient knowledge (belief) for me from C and C++ days. I swear there was a feature where you could link (or lock, or connect?) an output stream to an input stream and reading from the input stream would automatically flush the output stream.
>
> And I've been under the impression that stdin and stdout were such streams. But the internet does not agree with me. Was I dreaming? Was that a special thing about C++'s cout and cin?
>
> Help! Losing my mind...
>
> Ali
>
> P.S. Regardless, an automatic flush feature would be nice between stdin and stdout. But I wouldn't want that unless it "is a tty". Hm... I think I see now.

I bet you are mixing it up with connecting FILE streams to iostreams.

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

On 17.02.22 01:36, Ali Çehreli wrote:
> Was that a special thing about C++'s cout and cin?
> Help! Losing my mind... 
Afaik it's a more general feature of streams and for cin/cout, the following works:

std::cin.tie(nullptr);    // untie cin and cout
std::cin.tie(&std::cout); // tie cin and cout (the default)

On 2/16/22 23:19, Paulo Pinto wrote:

> I bet you are mixing it up with connecting FILE streams to iostreams.
>
> https://en.cppreference.com/w/cpp/io/ios_base/sync_with_stdio

Thank you. That must be it.

Regardless whether the automatic flush is standard or not, it is indeed the case at least in a terminal. When I run the following program without version=input (as commented out below), I see the output in waves of 1024 characters. (The first wave appears after about 3 seconds.)

However, when I run it with version=input, I see that the output is automatically flushed before the input:

import std.stdio;
import core.thread;

// version = input;
enum inputPeriod = 10;

void main() {
  foreach (i; 1 .. 10_000) {
    Thread.sleep(10.msecs);
    write(' ', i);

    version (input) {
      if (i % inputPeriod == 0) {
        write("Enter a char: ");
        char c;
        readf(" %s", &c);
      }
    }
  }
}

It's perhaps the terminal, which me likes. No big deal...

Ali

On 2/17/22 00:02, Timon Gehr wrote:
> On 17.02.22 01:36, Ali Çehreli wrote:
>> Was that a special thing about C++'s cout and cin?
>> Help! Losing my mind...
> Afaik it's a more general feature of streams and for cin/cout, the
> following works:
>
> std::cin.tie(nullptr);    // untie cin and cout
> std::cin.tie(&std::cout); // tie cin and cout (the default)

That's the one! I misremembered "tie" as "link".

Ali