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

Alexander Panek alexander.panek at brainsware.org
Sat Feb 9 03:20:03 PST 2008


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.

Just my two nitpicking cents. :)



More information about the Digitalmars-d mailing list