`<xiosbase>`: `std::ios_base::sync_with_stdio` has no effect in VS

[fsb4000]

Describe the bug

std::ios_base::sync_with_stdio has no effect in the STL but cout becomes much faster after calling sync_with_stdio on mingw + libstdc++ .

#include <cstdio>
#include <ctime>
#include <iostream>
using namespace std;
int main() {
    ios::sync_with_stdio(false);

    clock_t start, end;
    start = clock();

    for (int i = 0; i < 1e+4; i++) {
        cout << i;
    }

    end = clock();
    cout << endl;
    cout << end - start << endl;
    return 0;
}

Expected behavior

sync_with_stdio should give some performance.

STL version

Microsoft Visual Studio Community 2022
Version 17.6.0 Preview 3.0

Additional context

Devcom-10347093

I suggested to the user to add setvbuf(stdout, nullptr, _IOLBF, 16384); after sync_with_stdio but this optimization is still missing.

[frederick-vs-ja]

FWIW, I believe std::ios_base::sync_with_stdio has no effect in libc++ either (see also LLVM-21192).

I'm not sure whether this is by design.

[heheda123123]

But this problem has nothing to do with syn_with_stdio, it is caused by stdour not buffering. This means that functions such as printf will also be affected and the output will be slower.

[fsb4000]

@heheda123123 I believe we cannot enable buffering by default: https://github.com/microsoft/STL/issues/605#issuecomment-881972414 But I think we can enable buffering for cout, wcout, etc when ios::sync_with_stdio(false); is called

[StephanTLavavej]

@barcharcraz made the excellent point that we totally don't care about ancient msvcrt.dll behavior on Windows, so it would be a useful comparison to see how MinGW using the modern ucrtbase.dll behaves - this would be a relevant comparison for us as we use the same UCRT.