www.digitalmars.com [Home] [Search] [D]

Last update Feb 4, 2002


Classes

The object-oriented features of D all come from classes. The class heirarchy has as its root the class Object. Object defines a minimum level of functionality that each derived class has, and a default implementation for that functionality.

Classes are programmer defined types. Support for classes are what make D an object oriented language, giving it encapsulation, inheritance, and polymorphism. D classes support the single inheritance paradigm, extended by adding support for interfaces. Class objects are instantiated by reference only.

A class can be exported, which means its name and all its non-private members are exposed externally to the DLL or EXE.

A class declaration is defined:

	ClassDeclaration:
		class Identifier [SuperClass {, InterfaceClass }] ClassBody

	SuperClass:
		: Identifier

	InterfaceClass:
		Identifier

	ClassBody:
		{ Declarations }
Classes consist of:
super class
interfaces
dynamic fields
static fields
types
functions
static functions
dynamic functions
constructors
destructors
static constructors
static destructors
invariants
unit tests
A class is defined:
	class Foo
	{
	    ... members ...
	}
Note that there is no trailing ; after the closing } of the class definition. It is also not possible to declare a variable var like:
	class Foo { } var;
Instead:
	class Foo { }
	Foo var;

Fields

Class members are always accessed with the . operator. There are no :: or -> operators as in C++.

The D compiler is free to rearrange the order of fields in a class to optimally pack them in an implementation-defined manner. Hence, alignment statements, anonymous structs, and anonymous unions are not allowed in classes because they are data layout mechanisms. Consider the fields much like the local variables in a function - the compiler assigns some to registers and shuffles others around all to get the optimal stack frame layout. This frees the code designer to organize the fields in a manner that makes the code more readable rather than being forced to organize it according to machine optimization rules. Explicit control of field layout is provided by struct/union types, not classes.

In C++, it is common practice to define a field, along with "object-oriented" get and set functions for it:

	class Abc
	{	int property;
		void setProperty(int newproperty) { property = newproperty; }
		int getProperty() { return property; }
	};

	Abc a;
	a.setProperty(3);
	int x = a.getProperty();
	
All this is quite a bit of typing, and it tends to make code unreadable by filling it with getProperty() and setProperty() calls. In D, get'ers and set'ers take advantage of the idea that an lvalue is a set'er, and an rvalue is a get'er:
	class Abc
	{	int myprop;
		void property(int newproperty) { myprop = newproperty; } // set'er
		int property() { return myprop; }	// get'er
	}
	
which is used as:
	Abc a;
	a.property = 3;		// equivalent to a.property(3)
	int x = a.property;		// equivalent to int x = a.property()
	
Thus, in D you can treat a property like it was a simple field name. A property can start out actually being a simple field name, but if later if becomes necessary to make getting and setting it function calls, no code needs to be modified other than the class definition.

Super Class

All classes inherit from a super class. If one is not specified, it inherits from Object. Object forms the root of the D class inheritance heirarchy.

Constructors

Members are always initialized to zero, except for floating point members which are initialized to NAN. This eliminates an entire class of obscure problems that come from neglecting to initialize a member in one of the constructors. Additionally, the beauty of the NAN initialization is that any floating pointoperation with any NAN operand produces a NAN result. In the class definition, the programmer can supply a static initializer to be used instead of the default:
	class Abc
	{
		long bar = 7;		// set default initialization
	}
	
[NOTE: should explicit static initialization be required for all members?]

D constructors are not defined by using the name of the class, but by using the this keyword:

	class Foo
	{
		this(int x)		// declare constructor for Foo
		{ .
		}
		this()
		{.
		}
	}
	
This eliminates the tedium of retyping long class names over, it matches the use of the constructor, and is analogous to using 'super' to call the base class constructor. Also, since D requires an explicit return type for functions, it eliminates the syntactical ambiguity of constructors having no explicit return type.

C++ constructors have a complex syntax to initialize the base class. This clumsiness becomes even more onerous and error prone when there are several constructors, each with quite a bit of parallel code in common. D eliminates this by allowing one constructor to call another at any point - the constructor is really just another function. The vptr initialization is performed before the constructor is ever called (by the new operator). The base class constructor is explicitly called by the name "super".

	class A { this(int y) { } }

	class B : A
	{	int j;
		this()
		{
		    ...blah...
		    super(3);		// call base constructor A(3)
		    ...blah...
		    this(6);
		}
		this(int i)
		{
		    super(4);
		    j = 3;
		}
	}
	
D objects are created with the new syntax:
	A a = new A(3);
	
The following steps happen:
  1. Storage is allocated for the object. If this fails, rather than return null, an OutOfMemoryException is thrown. Thus, tedious checks for null references are unnecessary.
  2. The raw data is statically initialized using the values provided in the class definition. The vtbl pointer is assigned as part of this. This ensures that constructors are passed fully formed objects. This operation is equivalent to doing a memcpy() of a static version of the object onto the newly allocated one, although more advanced compilers may be able to optimize much of this away.
  3. If there is a constructor defined for the class, the constructor matching the argument list is called. It is that constructor's responsibility to call any base class constructor.

Destructors

The garbage collector calls the destructor function when the object is deleted. The syntax is:
	class Foo
	{
		~this()		// destructor for Foo
		{
		}
	}
	
There can be only one destructor per class, the destructor does not have any parameters, and has no attributes. It is always virtual.

The destructor is expected to release any resources held by the object.

The program can explicitly inform the garbage collector that an object is no longer referred to (with the delete expression), and then the garbage collector calls the destructor immediately, and adds the object's memory to the free storage. The destructor is guaranteed to never be called twice.

The destructor for the super class automatically gets called when the destructor ends. There is no way to call the super destructor explicitly.

Static Constructors

A static constructor is defined as a function that performs initializations before the main() function gets control. Static constructors are used to initialize static class members with values that cannot be computed at compile time.

Static constructors in other languages are built implicitly by using member initializers that can't be computed at compile time. The trouble with this stems from not having good control over exactly when the code is executed, for example:

	class Foo
	{
	    static int a = b + 1;
	    static int b = a * 2;
	}
	
What values do a and b end up with, what order are the initializations executed in, what are the values of a and b before the initializations are run, is this a compile error, or is this a runtime error? Additional confusion comes from it not being obvious if an initializer is static or dynamic.

D makes this simple. All member initializations must be determinable by the compiler at compile time, hence there is no order-of-evaluation dependency for member initializations, and it is not possible to read a value that has not been initialized. Dynamic initialization is performed by a static constructor, defined with a special syntax static this().

	class Foo
	{
	    static int a;		// default initialized to 0
	    static int b = 1;
	    static int c = b + a;	// error, not a constant initializer

	    static this()		// static constructor
	    {
		a = b + 1;		// a is set to 2
		b = a * 2;		// b is set to 4
	    }
	}
	
static this() is called by the startup code before main() is called. If it returns normally (does not throw an exception), the static destructor is added to the list of function to be called on program termination. Static constructors have empty parameter lists.

A current weakness of the static constructors is that the order in which they are called is not defined. Hence, for the time being, write the static constructors to be order independent. This problem needs to be addressed in future versions.

Static Destructor

A static destructor is defined as a special static function with the syntax static ~this().
	class Foo
	{
	    static ~this()		// static destructor
	    {
	    }
	}
	
A static constructor gets called on program termination, but only if the static constructor completed successfully. Static destructors have empty parameter lists. Static destructors get called in the reverse order that the static constructors were called in.

Class Invariants

Class invariants are used to specify characteristics of a class that always must be true (except while executing a member function). For example, a class representing a date might have an invariant that the day must be 1..31 and the hour must be 0..23:
    class Date
    {
	int day;
	int hour;

	invariant()
	{
	    assert(1 <= day && day <= 31);
	    assert(0 <= hour && hour < 24);
	}
    }
The class invariant is a contract saying that the asserts must hold true. The invariant is checked when a class constructor completes, at the start of the class destructor, before a public or exported member is run, and after a public or exported function finishes. The invariant can be checked when a class object is the argument to an assert() expression, as:
	Date mydate;
	...
	assert(mydate);		// check that class Date invariant holds
If the invariant fails, it throws an InvariantException. Class invariants are inherited, that is, any class invariant is implicitly anded with the invariants of its base classes.

There can be only one invariant() function per class.

When compiling for release, the invariant code is not generated, and the compiled program runs at maximum speed.

Unit Tests

Unit tests are a series of test cases applied to a class to determine if it is working properly. Ideally, unit tests should be run every time a program is compiled. The best way to make sure that unit tests do get run, and that they are maintained along with the class code is to put the test code right in with the class implementation code.

D classes can have a special member function called:

	unittest
	{
	    ...test code...
	}
	
The test() functions for all the classes in the program get called after static initialization is done and before the main function is called. A compiler or linker switch will remove the test code from the final build.

For example, given a class Sum that is used to add two values:

	class Sum
	{
	    int add(int x, int y) { return x + y; }

	    unittest
	    {
		assert(add(3,4) == 7);
		assert(add(-2,0) == -2);
	    }
	}
	
There can be only one unittest function per class.
Copyright (c) 1999-2002 by Digital Mars, All Rights Reserved