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