open, close, dup, dup2, lseek, read, write, fileno, etc.

[Leandro Lucarella]

Alexander Panek, el  9 de febrero a las 12:20 me escribiste:
> Walter Bright wrote:
> >Janice Caron wrote:
> >>On 09/02/2008, Walter Bright <newshound1 at digitalmars.com> wrote:
> >>>Going directly to the underlying OS functions makes for faster, more
> >>>efficient I/O. Calling open, close, etc., on Windows makes for poor
> >>>performance, because those functions are layered on top of the Windows
> >>>I/O functions.
> >>
> >>Thanks for the answer. Though my question wasn't "Why does
> >>std.stream.File use them?", it was "Why can't I use them?", which is a
> >>slightly different question, and I see no reason for prohibition.
> >You can use them - they are in the C runtime library for Windows. Just put in the declarations for them. You'll be disappointed, though. They are NOT part of 
> >Windows, they are C runtime functions which mostly emulate the linux ones.
> >You're better off skipping the middleman.
> >>It is simpler easier to write platform-independent code if you can use
> >>open() and close(), because then you don't have to do
> >>
> >>    version(Windows) { h = wide ? CreateFileW() : CreateFileA(); }
> >>    version(linux) { h = open(); }
> >>
> >>Platform independent code is also inherently easier to test, if you
> >>don't happen to have a linux platform handy.
> >To write platform independent code, why not use the D I/O facilities? That is the point of them. If they are deficient, it is better to enhance them than use 
> >open/close/read/write/dup.
> >open/close/etc. are NOT platform independence. They are low level unix api functions. For example, for open() on windows, you have to go through one layer to 
> >CreateFileA() (and a lot of messing about trying to convert unix-style modes and permissions to windows-style), and internal to Windows, CreateFileA() 
> >executes a conversion to go to CreateFileW().
> >>I wasn't complaining though - it is trivially easy to import those
> >>functions with extern(C) so it's hardly a big deal. I was just
> >>curious.
> >I advise against using them because they are the wrong abstraction to use. For example, they are a direct reflection of the linux filesystem, not the Windows 
> >filesystem.
> 
> I am not certainly sure, but I do think open, close & co are POSIX functions, not Linux functions per se. They're available on almost all modern Unices. So 
> actually, they are what one would call cross platform. They're just a step-child on Windows, coming with the POSIX subsystem.

Yes, and this reminds me why there is no "posix" version (like in Tango
AFAIK). It seems to me a little lame to have a "linux" version where
mostly all the imports have *posix* functions and can be used in any
*posix* sysm (which is even more wide than Unices, as said here Windows
has a -poor- posix API, and QNX 6 -clearly not a Unix- is posix too).

Posix is a great way to do portable code. I think it would be great if D
had better (and D-ish) Posix "bindings".

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
La máquina de la moneda, mirá como te queda!
	-- Sidharta Kiwi