stdio line-streaming revisited

[kris]

Sean Kelly wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
> 
>>
>> So what's the recommended use of Cout?
>>
>> (a) If you do stdio, use Cout (and don't forget to flush Cout manually 
>> every time you plan to read from Cin).
> 
> 
> Oh right, this is what tie() is for with iostreams.  It's come up before 
> in the past, though I can't recall if any conclusions were reached. I'll 
> admit that the current behavior is a tad confusing here though.

I'm not entirely sure what causes the sky to fall down for Andrei here? 
Apparently there's some kind of crisis due to a need to flush a "prompt" 
to the console before reading some related input? e.g. there's anguish over

   Cout ("name? ").flush;
   Cin.get();

Sure, a little sugar in the form of tie() might be nice, but there's 
nothing fundamentally wrong with the current approach as it is, IMO. 
Anything else is just gravy. I sure hope there ain't no crisis here ;)

If I've got this wrong, Sean, I'd appreciate clarification?



>> (b) But not for multithreaded programs that do stdio. For those, use 
>> the logger facility. If you want multithreaded output to stdout, copy 
>> the code from 
>> http://www.dsource.org/projects/tango/wiki/ChapterLogging into your 
>> program. Be careful that that code might be incorrect; the manual 
>> doesn't specify. If it is correct, be careful with what you do inside 
>> that code, because you could deadlock yourself.
> 
> 
> To be fair, this is mostly a documentation issue.  Though it may be that 
> the logger could be made easier to use for your example.  I'll have to 
> look at the logger in more detail before I say any more--I've only used 
> it a handful of times.

 From what I recall, logging is expected to be used by engineers: that 
is, if you write yourself a stupid plug-in for the logging framework, 
then you have no-one but yourself to blame. Similar silliness could be 
applied to, say, the GC ~ "OMG! I can write a dtor that borks the GC 
when it calls me!" ... this is the playground of children and fools alone.

On the other hand, using the logger is not a requirment. While it 
exposes a powerful tool, a lot of folk will simply never see the value 
in it, or find other (perhaps valid) reason to not use it. People, in 
general, don't much care for change; they'll fight it tooth and nail, 
especially those who are used to getting their own way all the time.

As far as atomic console output is concerned, I feel it's a little like 
the arguments over Container api's being synchronized or not. There are 
valid cases where such apis can show benefit when synchronized, but most 
people realize that the common tradeoffs are not particularly great.

I see similar concerns with console usage: for those cases that actually 
need atomic console ouput, it's certinaly possible to write a trivial 
wrapper around it and synchronize that instead (it might even wind up in 
the library). However, it seems wholly at odds to have individuals 
howling for crazy-shizzle throughput on one hand, and at the same time 
condemning a lack of atomicity for a select number of cases that /might/ 
use it ;)

There's also the issue of multi-component atomicity, where you need a 
series of constructs sent to some output as a single entity, protected 
from the whims of multiple threads. An atomic console does nothing much 
to help in this more general case, in the same way that multiple threads 
writing to the same file are not co-ordinated across multiple calls. The 
issue is a larger one than might meet the eye, and band-aids are not an 
appropriate solution IMO. Would be interested if folks had some ideas 
about this in the larger scale, but on a different thread ... for 
example, D has these nice delegates with lazy expressions ~ something 
like that might be used for such purposes?

Anyway; seems like the poor old console has to do quad-duty, while all 
the other available tools go on vacation. This is not an appropriate 
strategy in general, and I'm not super-enthuisiastic about encouraging 
people to use Cout to chop wood.