Philosophy of how OS API imports are laid out in druntime

Walter Bright newshound2 at digitalmars.com
Thu Mar 6 13:35:35 PST 2014


On 3/5/2014 9:16 AM, Regan Heath wrote:
> 1. Walter wants the C include to map directly to a D import.
> 2. Sean wants to be able to ensure he does not import and use a platform
> specific function/definiton in a cross platform application.
>
> Is that about right?

Yes.

> To clarify some points..
>
> @Walter are you asking for ALL includes even #include <windows.h> to map?

Yes. Of course, if you're on linux and attempt to import core.windows, you 
should expect a compilation failure, just as you would in C with:

     #include <windows.h>

> For example, <sys/ioctl.h> is not a windows header and would not be considered
> "cross platform".

I'd expect:

     import core.sys.ioctl;

to work on linux systems and fail to compile on windows systems. Just as one 
would expect in C with:

     #include <sys/ioctl.h>


> I have the following include folders in Visual Studio 2008:
> C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include        - posix,
> c[++] std library headers
> C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\atlmfc\include - ATL/MFC
> headers
> C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Include          - windows
> specific headers
>
> would you only expect to map headers from the first of those, and not the rest?

The first, yes, ATL and MFC are not usable with D, and windows, yes.


> That first folder contains 184 files which correlate to posix, and c[++]
> standard library headers.

We wouldn't need the posix or C++ ones.


> It seems this will satisfy Walter without impacting Sean.. other than being
> loads of "unnecessary" modules from your perspective.

Any install on Linux should be able to delete any freebsd.d, osx, windows files 
with impunity, etc.



More information about the Digitalmars-d mailing list