The D Programming Language

Familiarize yourself with the powerful compiled and managed language D.
Exceptions

As a rule, D uses exceptions for error handling as opposed to error codes. D uses the try-catch-finally model for exceptions, which allows cleanup code to be inserted conveniently in the finally block. For those cases when the finally block is insufficient, scope statements come in quite handy.

Classes

Like any object-oriented language, D has the ability to create object classes. One major difference is the lack of a virtual keyword, unlike with C++. This is handled automatically by the compiler. D uses a single-inheritance paradigm, relying on interfaces and mixins, which are discussed later to fill in the gaps. Classes are passed by reference rather than by value, so the programmer doesn't have to worry about treating it like a pointer. Furthermore, there is no -> or :: operator; the . is used in all situations to access members of structs and classes. All classes derive from Object, the root of the inheritance hierarchy:

class MyClass {
        int i;
        char[] str;
        void doSomething() { ... };
}

Classes can have defined properties by having multiple functions with the same name:

class Person {
        private char[] PName;
        char[] name() {return PName;}
        void name(char[] str)
        {
        // do whatever's necessary to update any
        // other places where the name is stored
        PName = name;
        }
}

Classes can have constructors and destructors, namely this and ~this:

class MyClass {
        this() { writefln("Constructor called");}
        this(int i) {
          writefln("Constructor called with %d", i);
        }
        ~this() { writefln("Goodbye");}

Classes have access to the constructors of their base class:

this(int i) {
        super(1, 32, i); // super is the name of the
                         // base class constructor
}

Classes can be declared inside other classes or functions, and they have access to the variables in that scope. They also can overload operators, such as comparison, to make working with them more obvious, as in C++.

Classes can have invariants, which are contracts that are checked at the end of constructors, before destructors and before public members, but removed when compiling for release:

class Date
{
int day;
int hour;
invariant
    {
        assert(1 <= day && day <= 31);
        assert(0 <= hour && hour < 24);
    }
}

To check whether two class references are pointing to the same class, use the is operator:

MyClass c1 = new MyClass;
MyClass c2;
if(c1 is c2)
        writefln("These point to the same thing.");
Interfaces

An interface is a set of functions that any class deriving from it must implement:

interface Animal {
        void eat(Food what);
        void walk(int direction);
        void makeSound();
}
Functions

In D, there is no inline keyword—the compiler decides which functions to inline, so the programmer doesn't even have to worry about it. Functions can be overloaded—that is to say, two functions with the same name can take different parameters, but the compiler is smart enough to know which one you're talking about:

void func(int i) // can implicitly take
                 // longs and shorts too
{...}

void func(char[] str)
{...}

void main()
{
        func(23);
        func("hello");
}

Function parameters can be either in, out, inout or lazy, with in being the default behavior. Out parameters are simple outputs:

void func(out int i)
{
        I += 4;
}

void main()
{
        int n = 5;
        writefln(n);
        func(n);
        writefln(n);
}

inout parameters are read/write, but no new copy is created:

void func(inout int i)
{
        if(i >= 0)
                ..
        else
                ..
}

Lazy parameters are computed only when they are needed. For example, let's say you called a function like this:

log("Log: error at "~toString(i)~" file not found.");

Notice that every time you call it, the strings are concatenated and passed to the function. The lazy storage class means that the strings are put together only if they are called upon, increasing performance and efficiency. Nested functions in D allow the nesting of functions within other functions:

void main()
{
        void func()
        {
                ..
        }
}

Nested functions have read/write access to the variables of the enclosing function:

void main()
{
int i;
        void func()
        {
                writefln(i + 1);
        }
}
______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

What a badly designed language

rae's picture

I can't see any better than C/C++ or Python.

the "~" concatenating operator is ugly than any other language,

the gc makes it not a pure compiling language.

It's pure compiling

Anonymous's picture

It's pure compiling language! "~" is used becouse, "+" means addition, not concatenating. You can find rational arguments for this and other problems on D web page.

BTW. "inout" parameters are now renamed to "ref".

As of 1.011

Anonymous's picture

"BTW. 'inout' parameters are now renamed to 'ref'."

As of 1.011

Funny though, its badly designed because it uses ~ and has gc. And I wonder what pure compiling means if gc makes this no longer true?

Why makes gc pure compiling no longer true

Anonymous's picture

Why makes gc pure compiling (whatever that means) no longer true ? GC is done by the runtime and has nothing to do with compiling. D is a "pure compiling" language (as pure as you can get - there is nothing more pure than compiling into platform dependent native code). And why is a language badly designed just because it has the option to use garbage collection (in D you can manage memory by yourself and turn garbage collection completely off, if you want to) ?

Using ~ for concatenating arrays and not + makes sense because your not adding strings like you are adding numbers. But that might be just a matter of taste.

But if these two things are the only criterions for you to decide if a language is good or bad designed, you should better not become a language designer.

Improvements over C++

Anonymous's picture

For a (not complete) list of things which are "improvements" over C++ just take a look at

http://eureka3d.com/blog/2006/the-d-progamming-language-a-pleasant-surpr...

As always this is a matter of taste and personal preference. But C++ had to be designed to be backward compatible to C, so some things could not be as clean designed as they should be and make the language more complicated and error prone.

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix