www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - core.sys/core.stdc vs. std.c?

reply David Nadlinger <see klickverbot.at> writes:
core.stdc is the place for C standard library modules, core.sys.* are 
where the C operating system header translations reside – this is our 
current policy, right? If so (I can't actually remember any formal 
decision or discussion), is there a reason we still have so much code in 
std.c?

David
Jun 11 2011
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On 2011-06-11 23:38, David Nadlinger wrote:
 core.stdc is the place for C standard library modules, core.sys.* are
 where the C operating system header translations reside =E2=80=93 this is=

 current policy, right? If so (I can't actually remember any formal
 decision or discussion), is there a reason we still have so much code in
 std.c?

IIRC, all of the standard C bindings are supposed to be in core. std.c is=20 where they used to be, and I believe that the majority of std.c merely=20 publically imports the corresponding modules in core. The modules in std.c= =20 should probably be put on the path to deprecation now. I believe that they= =20 have only been left around for backwards compatability. =2D Jonathan M Davis
Jun 11 2011
prev sibling next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 12.06.2011 08:38, schrieb David Nadlinger:
 core.stdc is the place for C standard library modules, core.sys.* are
 where the C operating system header translations reside – this is our
 current policy, right? If so (I can't actually remember any formal
 decision or discussion), is there a reason we still have so much code in
 std.c?
 
 David

And why is core.stdc not listed on http://www.digitalmars.com/d/2.0/phobos/phobos.html and http://d-programming-language.org/phobos/index.html ? Furthermore it'd be nice if the functions contained there were documented or at least listed. Cheers, - Daniel
Jun 11 2011
parent KennyTM~ <kennytm gmail.com> writes:
On Jun 12, 11 14:44, Daniel Gibson wrote:
 Am 12.06.2011 08:38, schrieb David Nadlinger:
 core.stdc is the place for C standard library modules, core.sys.* are
 where the C operating system header translations reside – this is our
 current policy, right? If so (I can't actually remember any formal
 decision or discussion), is there a reason we still have so much code in
 std.c?

 David

And why is core.stdc not listed on http://www.digitalmars.com/d/2.0/phobos/phobos.html and http://d-programming-language.org/phobos/index.html ? Furthermore it'd be nice if the functions contained there were documented or at least listed. Cheers, - Daniel

http://d.puremagic.com/issues/show_bug.cgi?id=5872
Jun 12 2011
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/12/11 1:38 AM, David Nadlinger wrote:
 core.stdc is the place for C standard library modules, core.sys.* are
 where the C operating system header translations reside – this is our
 current policy, right? If so (I can't actually remember any formal
 decision or discussion), is there a reason we still have so much code in
 std.c?

 David

The reason is a smart GSoC student didn't yet come and deprecate them :o). Andrei
Jun 12 2011
next sibling parent David Nadlinger <see klickverbot.at> writes:
On 6/12/11 5:06 PM, Andrei Alexandrescu wrote:
 On 6/12/11 1:38 AM, David Nadlinger wrote:
 core.stdc is the place for C standard library modules, core.sys.* are
 where the C operating system header translations reside – this is our
 current policy, right? If so (I can't actually remember any formal
 decision or discussion), is there a reason we still have so much code in
 std.c?

 David

The reason is a smart GSoC student didn't yet come and deprecate them :o).

Smart? Can't possibly be me… ;) On a closer look, I discovered that contrary to core.sys.posix and core.sys.osx, which only have C header translations, core.sys.windows.* also contains support code like backtrace.d, thradaux.d, etc. Is the »official« package structure actually documented anywhere? David
Jun 12 2011
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
The windows bit was more an issue of that we needed the code somewhere and i=
t was windows-specific, so sys.windows seemed a passable choice. The alterna=
tive would be core.internal, though I'm trying to avoid the need for that ap=
proach. If you have suggestions for how to handle this, please let me know :=
-)

Sent from my iPhone

On Jun 12, 2011, at 8:37 AM, David Nadlinger <see klickverbot.at> wrote:

 On 6/12/11 5:06 PM, Andrei Alexandrescu wrote:
 On 6/12/11 1:38 AM, David Nadlinger wrote:
 core.stdc is the place for C standard library modules, core.sys.* are
 where the C operating system header translations reside =E2=80=93 this i=



 current policy, right? If so (I can't actually remember any formal
 decision or discussion), is there a reason we still have so much code in=



 std.c?
=20
 David

The reason is a smart GSoC student didn't yet come and deprecate them :o)=


=20
 Smart? Can't possibly be me=E2=80=A6 ;)
=20
 On a closer look, I discovered that contrary to core.sys.posix and core.sy=

ns support code like backtrace.d, thradaux.d, etc.
=20
 Is the =C2=BBofficial=C2=AB package structure actually documented anywhere=

=20
 David

Jun 12 2011