hi all,

i am trying out a trivial daytime-client for getting my feet wet with sockets programming using D.

all "unistd.h" stuff e.g. read/write/dup/dup2/... have been exported to D via the "std.c.linux.linux" module as defined in "std/c/linux/linux.d".

i was just curious about the "std.c.linux.linux" module name. any reason for not using a simple "std.c.linux" or perhaps "std.c.linux.unistd" ?

thanks
anupam

anupam kapoor <anupam.kapoor@gmail.com> spewed this unto the Network:
> hi all,
> 
> i am trying out a trivial daytime-client for getting my feet wet with sockets programming using D.

> all "unistd.h" stuff e.g. read/write/dup/dup2/... have been exported to D via the "std.c.linux.linux" module as defined in "std/c/linux/linux.d".

> i was just curious about the "std.c.linux.linux" module name. any reason for not using a simple "std.c.linux" or perhaps "std.c.linux.unistd" ?

> thanks
> anupam

This makes me think: What happens when D is implemented on other
Unix systems that have almost the exact same API? Will they still
use std.c.linux.linux, or will you need to use, for instance,
std.c.solaris.solaris to access fork(2) on Solaris, and
std.c.linux.linux to access fork(2) on Linux? Wouldn't it
be sort of silly to have to import a different module to get
the same function?

Some posts in this newsgroup imply that there is already a D compiler for Mac OS X, which implies that this issue has already come up. Which of these modules must be imported to access fork(2) on Mac OS X? :

	std.c.linux.linux
	std.c.macosx.macosx
	std.c.darwin.darwin
	std.c.freebsd.freebas
	std.c.mach.mach

BTW, if you're looking at unistd.h just for sockets, it would seem that you are looking in the wrong place. I am looking at some D source code right now that gets a class called TcpSocket from std.socket. Therefore, D supports sockets in its standard library.

The D socket class seems to support both buffered and unbuffered I/O.

Here is a completely untested example program. Keep in mind that I have not actually installed a D compiler on my system. This is based on my impression of how it "seems to work:"

import std.socket;
import std.socketstream;

int main() {
	SocketStream stream =
	   new SocketStream(new TcpSocket(new InternetAddress("something.com", 80)));

	stream.writeString("GET / HTTP/1.0\r\n\r\n");
	// Et cetera.
}

nobody@nowhere.nonet wrote:

>> i was just curious about the "std.c.linux.linux" module name. any reason
>> for not using a simple "std.c.linux" or perhaps "std.c.linux.unistd" ?

D does not allow to use the same name as a directory and file
for modules, so there is usually the name duplicated in there.
(e.g. std/c/linux/*.d and std/c/linux.d are not both allowed)

> This makes me think: What happens when D is implemented on other
> Unix systems that have almost the exact same API? Will they still
> use std.c.linux.linux, or will you need to use, for instance,
> std.c.solaris.solaris to access fork(2) on Solaris, and
> std.c.linux.linux to access fork(2) on Linux? Wouldn't it
> be sort of silly to have to import a different module to get
> the same function? 

As far as I understand Walter's comments on the subject, having
different modules for the same function IS the preferred approach.
Then again, DMD doesn't support the other Unix systems just yet...

GDC does bundle them together in a version(Unix), using autoconf.
Tango uses version(Posix) to mean the same thing, and sets this
version to the compiler with the "-version=Posix -version=Tango"

> Some posts in this newsgroup imply that there is already a D
> compiler for Mac OS X, which implies that this issue has already
> come up. Which of these modules must be imported to access fork(2)
> on Mac OS X? :
> 
> 	std.c.linux.linux
> 	std.c.macosx.macosx
> 	std.c.darwin.darwin
> 	std.c.freebsd.freebas
> 	std.c.mach.mach

None of them, you use std.c.unix.unix to access fork with GDC.

There used to be a std.c.darwin.darwin, but it is gone now...
Old std.c.linux.linux is being provided for DMD compatibility.
But using the autoconf'd module std.c.unix.unix is preferred.

--anders