About the D Language

See http://www.digitalmars.com/d/ for information and specification on the D programming language. Otherwise Google Directory - Computers > Programming > Languages > D has some great links.

Thoughts and Suggestions for D

When I began using D I was confused by the version conditions used for different operating systems. Since looking at a lot of D code in phobos and other projects, I've spent some time working out what we attempt to accomplish with the versions Windows, Linux, Posix, as to me they seemed to be missing the target.

Standard C Library

In the language specification, it states that D relies on the standard C runtime library of the target environment, so...

These libraries aim to implement, in whole, in part, or extended, a standard C library relevant to their target kernel/environment, shown here using possible version identifiers:

• dietlibc - An embedded libc.
• freebsd - FreeBSD's own libc.
• glibc - Commonly the Linux standard C library, but could be used by others too.
• minix - Minix libc.
• msvcrt - Microsoft Standard C Library.
• netbsd - NetBSD libc.
• newlib - An embedded libc.
• openbsd - OpenBSD libc.
• darwin - Apple libc.
• opendarwin - OpenDarwin libc.
• uclibc - uClibc embedded library.
• more...

Those implementations may or may not, conform with these particular standards, created to allow cross platform software development in the C language:

• c89
• posix92 or posix1
• unix95
• posix96 or posix2
• unix98
• c99
• susv3

Of those standards created; c89 and c99 appear to be the only standards which solely target the standard C library. The others, as well as extensions to the C library, also define a Unix System standard, which can include around 160 utility programs such as cd, rmdir, ps, sed, grep, mailx, man, vi.

Therefore my suggestion for the layout of packages/modules for the standard D library is:

• std
• c
• assert
• complex
• ctype
• errno
• fenv
• float
• inttypes
• iso646
• limits
• locale
• math
• setjmp
• signal
• stdarg
• stdbool
• stddef
• stdint
• stdio
• stdlib
• string
• tgmath
• time
• wchar
• wctype
• unix
• aio
• cpio
• dirent
• dlfcn
• fcntl
• fmtmsg
• fnmatch
• ftw
• glob
• grp
• iconv
• langinfo
• libgen
• monetary
• mqueue
• ndbm
• netdb
• nl_types
• poll
• pthread
• pwd
• regex
• sched
• search
• semaphore
• spawn
• strings
• stropts
• syslog
• tar
• termios
• trace
• ucontext
• ulimit
• unistd
• utime
• utmpx
• wordexp
• arpa
• inet
• net
• if
• netinet
• in
• tcp
• sys
• ipc
• mman
• msg
• resource
• select
• sem
• shm
• socket
• stat
• statvfs
• time
• timeb
• times
• types
• uio
• un
• utsname
• wait

Obviously some of those items aren't actually required such as the assert module - but they are named one-to-one to standard C header files (as phobos does such as std.c.stdio). There is also obviously no need to deal with parts of unix and posix standards which specify utility programs.

In all of the above packages and modules, because they implement bindings to a C standard library, I believe the version()s available should be named based on the the possible C library being linked, rather than a standard or operating system. Therefore typically those I mentioned in the first list above as versions for starters.

I called the Standard C Library for Windows version(msvcrt) because that is the library linked to, but also because version(windows) is ambiguous due to the option of linking with other Standard C Library implementations on Windows such as mingw, cygwin, and maybe others.

FreeBSD, NetBSD, OpenBSD, Darwin, and others..., seem to call their standard C library as simply libc. I believe the standard C library commonly used on Linux (glibc) may also be used on other systems including the different *BSDs.

But also due to the possible quantity in versions it may be the case that modules in std.c and std.c.unix simply alias import from modules in packages with names like:

std.c.msvcrt - Microsoft standard C library
std.c.glibc - for glibc specific modules
std.c.glibc.linux - for Linux specific parts of glibc

std.c.unix.msvcrt - May have some support for unix features
std.c.unix.mingw
std.c.unix.glibc - for glibc implementation of unix extensions
std.c.unix.uclibc

Unix here meaning the standard C library extensions required for unix systems.

A lot should, but not always, overlap, so it would be good to be able to do:

version( msvcrt | glibc | darwin )
{
}
else version( mingw | cygwin )
{
}
else version( freebsd | netbsd | openbsd ) 
{
}
else
{
    // Failed due to (one of):
    // 1. Feature not available with this standard C library.
    // 2. Explicit definition of libc version required.
    // 3. Platform not supported.
    static assert(0);
}

This allows the modules in std.c and std.c.unix to expose the current cross platform C library APIs. Programs using modules just from these two standard packages would run on all supported systems and wouldn't need any particular version() conditions.

System Specific APIs

I think the following package hierarchy should be made available containing modules that bind to APIs that are operating system specific, as delivered by their vendor or creator, which relate more with version()s currently being used:

sys.windows // sys specific modules like:
  kernel
  user
  gdi
  winspool
  comdlg
  advapi
  comctl
  shell
  more...
sys.linux   // for direct syscalls not exposed in standard C lib
sys.mach    // modules for the mach micro-kernel in macosx etc
sys.macos   // sys specific modules such as Carbon
sys.solaris
sys.tru64
more...

But of course those systems also have sub-versions (which may or may not use packages for their specific versions):

sys.windows.win32  // Win32 API available on many versions
sys.windows.win64  // Win64 API only on newer NT variants
sys.windows.winfx  // Microsoft's new Longhorn API

sys.windows.95     // 95-ME variants
sys.windows.ce     // CE embedded variants
sys.windows.nt     // NT-2000-XP-2003 variants
sys.windows.vista  // Supposedly its the new name

sys.linux.v2_4
sys.linux.v2_6
sys.linux.v2_6_11

sys.mach.v3
sys.mach.v4
sys.mach.apple     // Apple's API may have extensions

sys.macos.v9
sys.macos.v10_2_8
sys.macos.v10_3_9
sys.macos.v10_4

To import all modules in a package, with files like this, it could work:

sys/windows.d   (containing imports for kernel, user, gdi, etc)

sys/windows/kernel.d
sys/windows/user.d
sys/windows/gdi.d

So someone writing a program could use import sys.windows; to import all the common modules relevant. As the windows.h C file mainly includes all the other headers, maybe even version = windows_lean_and_mean; import sys.windows; as you can do now in C using a #define.

Conclusion

We really need an excellent h2d tool.

What do you think? Comment

Architectures and Processor Variants

For the fun of it.

module archs;

version(ia32)
{
    version(i386) {}
    version(i486) {}
    version(pentium) {}
    version(pentium3) {}
    version(pentium4) {}
    version(athlon) {}
    version(cyrix) {}
    
    version(mmx) {}
    version(simd) {}
}

version(ia64) {} // I believe these two are
version(amd64) {}// not actually the same???

version(powerpc)
{
    version(ppc7450) {}
    version(altivec) {}
}

version(powerpc64)
{
    version(ppc970) {}
    version(power4) {}
    version(altivec) {}
}

version(alpha)
{
    version(ev6) {}
    version(ev7) {}
    version(ev7z) {}
}

version(arm)
{
    version(arm6) {}
    version(arm7) {}
    version(strongarm) {}
    version(xscale) {}
}

version(mips)
{
    version(mips3) {}
    version(r10000) {}
}

version(sparc) {}
version(sparc64) {}