The D Programming Language

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

D has a totally redesigned and highly flexible template system. For starters, the ! operator is used for template instantiation. This eliminates the numerous ambiguities caused by <> instantiation and is more readily recognizable. Here is a simple copier template:

template TCopy(t) {
        void copy(T from, out T to)
        {
                to = from;
        }
}

void main()
{
        int from = 7;
        int to;
        TCopy!(int).copy(from, to);
}

Template declarations can be aliased:

alias TFoo!(int) temp;

Templates can be specialized for different types, and the compiler deduces which type you are referring to:

template TFoo(T)        { ... } // #1
template TFoo(T : T[])  { ... } // #2
template TFoo(T : char) { ... } // #3
template TFoo(T,U,V)    { ... } // #4
alias TFoo!(int) foo1;          // instantiates #1
alias TFoo!(double[]) foo2;     // instantiates #2
                                // with T being double
alias TFoo!(char) foo3;        // instantiates #3
alias TFoo!(char, int) fooe;   // error, number of
                               // arguments mismatch
alias TFoo!(char, int, int) foo4; // instantiates #4
Function Templates

If a template has one member function and nothing else, it can be declared like this:

void TFunk(T) (T i)
{
..
}
Implicit Function Template Instantiation

Function templates can be instantiated implicitly, and the types of the arguments deduced:

TFoo!(int, char[]) (2,"foo");
TFoo(2, "foo");
Class Templates

In those cases when you need to declare a template and its only member is a class, use the following simplified syntax:

class MyTemplateClass (T)
{
..
}
Mixins

A mixin is just like cutting and pasting a template's code into a class; it doesn't create its own scope:

template TFoo(t)
{
        t i;
}

class test
{
        mixin TFoo!(int);
        this()
        {
                i = 5;
        }
}

void main()
{
        Test t = new Test;
        writefln(t.i);
}
Conclusion

D is a promising language that is able to supply many different needs in the programming community. Features such as arrays, SH syntax and type inference make D comparable to languages, such as Ruby and Python, in those regards, while still leaving the door open for low-level system programmers with the inline assembler and other features. D can be applied to many programming paradigms—be they object-oriented with classes and interfaces, generic programming with templates and mixins, procedural programming with functions and arrays, or any other. The garbage collector relieves the programmer of the need to manage all memory chunks manually, while still making it possible for those situations in which manual memory management is preferred. It brings in features of imperative languages, such as Lisp, with the lazy storage class, which drastically speeds up efficiency. The language is relatively stable, with the occasional new features or changes added in.

In short, D is a language ready for real-world deployment.

Ameer Armaly is a blind 18-year-old high-school senior. Among his interests are playing the guitar, programming and science fiction.

______________________

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.

Webcast
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers

Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.

Learn More

Sponsored by AMD

White Paper
Red Hat White Paper: Using an Open Source Framework to Catch the Bad Guy

Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6

Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.

Learn more about catching the bad guy in this free white paper.

Learn More

Sponsored by DLT Solutions