July 01, 2010
Steven Schveighoffer wrote:
> I really think D needs to replace FILE * with it's own buffering scheme.  That way we can control the underlying buffering and have access to it.  We can also take advantage of D features that aren't available in the underlying code, such as thread local storage to avoid taking global locks.

This isn't done because mixing D and C I/O is a desirable property.
July 01, 2010
On Thu, 01 Jul 2010 12:31:19 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> Steven Schveighoffer wrote:
>> I really think D needs to replace FILE * with it's own buffering scheme.  That way we can control the underlying buffering and have access to it.  We can also take advantage of D features that aren't available in the underlying code, such as thread local storage to avoid taking global locks.
>
> This isn't done because mixing D and C I/O is a desirable property.

It can still be this way, just have a special D buffer implementation that outputs to a FILE * or reads from it.  But I shouldn't be *required* to deal with FILE * when I open a file or network socket and only ever use it in D.

Even though it's desirable, there are considerable drawbacks that need to be justified.

-Steve
1 2 3
Next ›   Last »