March 22, 2007
Walter Bright Wrote:

> Andrei Alexandrescu (See Website For Email) wrote:
> > Walter Bright wrote:
> >> Turning off sync is cheating - D's readln does syncing.
> > 
> > I don't know exactly what sync'ing does in C++, but probably it isn't the locking that you are thinking of.
> 
> I think it means bringing the iostream I/O buffer in to sync with the stdio I/O buffer, i.e. you can mix printf and iostream output and it will appear in the same order the calls happen in the code.
> 

That's exactly what it does... Quite a few times I've had to 'optimize' C++ iostream code using sync_with_stdio().

> D's readln is inherently synced in this manner.

Which of course begs the question -- Could an overload be added so it doesn't sync (not the default)? Might be worth a test, and if the difference is significant keep it.
March 23, 2007
Dave wrote:
> Walter Bright Wrote:
>> Andrei Alexandrescu (See Website For Email) wrote:
>>> Walter Bright wrote:
>>>> Turning off sync is cheating - D's readln does syncing.
>>> I don't know exactly what sync'ing does in C++, but probably it isn't the locking that you are thinking of.
>> I think it means bringing the iostream I/O buffer in to sync with the stdio I/O buffer, i.e. you can mix printf and iostream output and it will appear in the same order the calls happen in the code.
>>
> 
> That's exactly what it does... Quite a few times I've had to 'optimize' C++ iostream code using sync_with_stdio().
> 
>> D's readln is inherently synced in this manner.
> 
> Which of course begs the question -- Could an overload be added so it doesn't sync (not the default)? Might be worth a test, and if the difference is significant keep it.

Since the data has to be buffered anyway, might as well use stdio's buffer. I don't know why iostream felt the need to reimplement the buffers - certainly it isn't for performance <g>.