stdio line-streaming revisited

[Andrei Alexandrescu (See Website For Email)]

Frits van Bommel wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> Frits van Bommel wrote:
>>> Andrei Alexandrescu (See Website For Email) wrote:
>>>> Sean Kelly wrote:
>>>>> Andrei Alexandrescu (See Website For Email) wrote:
>>>>>> That's great, however the interface has a problem too: it does not 
>>>>>> produce atomic strings in multithreaded programs.
>>>>>
>>>>> Which interface?  And are you talking about input or output?
>>>>
>>>> Cout. The thing is that the design using the syntax Cout(a)(b) is 
>>>> conducive to two separate calls to the library. I recall this has 
>>>> been briefly discussed here.
>>>
>>> Of course that could easily be fixed if either struct destructors or 
>>> scope class returning were to be added to the language. Then you 
>>> could just return something with a destructor that releases the lock.
>>
>> Struct destructors will be added, but typesafe variadics are already 
>> in. I think Cout(a, b) is the most natural interface to offer.
> 
> I dislike typesafe variadics for I/O, mainly because it'll instantiate a 
> new version for every parameter list. I/O functions will typically be 
> called with a lot of different parameter lists, which may lead to code 
> bloat.

I think this is not a problem (for a well-written library) as those many 
parameter lists will essentially be sliced and diced into the equivalent 
hand-written calls.

> However, my point in that post was that using the method I suggested 
> (the first call returning a struct with a destructor) also has the 
> advantage that it allows for backwards-compatibility. The current syntax 
> will continue to work, with the only difference being that now it'll be 
> thread-safe.

This is not going to work. Essentially you are giving the user the 
license to execute arbitrary code with locked files, a sure recipe for 
puzzling deadlocks. Cout(a, b) is the way.


Andrei