Tango / Phobos / future dilemma

Koroskin Denis 2korden at gmail.com
Tue May 27 08:03:55 PDT 2008


On Tue, 27 May 2008 18:49:26 +0400, Frits van Bommel  
<fvbommel at remwovexcapss.nl> wrote:

> Sascha Katzner wrote:
>> I see no reason why those two IO systems couldn't coexist on top of a  
>> common low level cache.
>
> (All of the statements below are AFAIK & IIRC from the newsgroup  
> discussions on this subject)
>
> I do:
> Walter seems convinced that using the libc buffering is the Right Thing  
> To Do(TM) because it allows intermixing of *printf(), putc*(), etc. with  
> writefln & friends without explicitly syncing them.
> The Tango devs have a good reason to use their own, separate, buffering  
> solution: the tests showing better performance. (And many people  
> consider it bad style to use C-style I/O in D programs anyway, so "it's  
> just not worth it" becomes a good argument pretty quickly here)
>
> This just doesn't allow a "common low level cache" since neither of  
> their buffering solutions allows the use of a common buffer unless the  
> other one switches (Phobos can't change libc while much of the Tango IO  
> functionality depends on using the custom buffer and its good  
> performance depends on interfacing directly to the OS[1])...
>
> In other words, it's a fundamental disagreement about how to best do I/O.
>
>
>
> [1] Also, changing the Tango I/O code to use libc instead of direct OS  
> calls isn't very helpful since it still won't be synced to C-style I/O  
> (there'll still be an extra buffer in front of the Tango stuff that  
> would only send stuff to libc when full or explicitly flushed).

C++ has both C-style stdio (fopen, fwrite, etc) and custom iostreams.
Both of them have overlapping functionality, and no one cares.

Since D can directly interface with C code and we can't throw away that,
C-style IO _will_ present in D. And that's Ok, I don't see any problems
here. Guys that think that it's the right way would use that, others would
use Tango way.


More information about the Digitalmars-d-learn mailing list