Ddoc $(SPEC_S Classes, $(P The object-oriented features of D all come from classes. The class hierarchy 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. ) $(P 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. ) $(P A class can be exported, which means its name and all its non-private members are exposed externally to the DLL or EXE. ) $(P A class declaration is defined: ) $(GRAMMAR $(I ClassDeclaration): $(B class) $(I Identifier) $(I BaseClassList)opt $(I ClassBody) $(I BaseClassList): $(B :) $(I SuperClass) $(B :) $(I SuperClass) $(I InterfaceClasses) $(B :) $(I InterfaceClass) $(I SuperClass): $(I Identifier) $(I Protection) $(I Identifier) $(I InterfaceClasses): $(I InterfaceClass) $(I InterfaceClass) $(I InterfaceClasses) $(I InterfaceClass): $(I Identifier) $(I Protection) $(I Identifier) $(I Protection): $(B private) $(B package) $(B public) $(B export) $(I ClassBody): $(B {) $(B }) $(B {) $(I ClassBodyDeclarations) $(B }) $(I ClassBodyDeclarations): $(I ClassBodyDeclaration) $(I ClassBodyDeclaration) $(I ClassBodyDeclarations) $(I ClassBodyDeclaration): $(I Declaration) $(GLINK Constructor) $(GLINK Destructor) $(GLINK StaticConstructor) $(GLINK StaticDestructor) $(GLINK Invariant) $(GLINK UnitTest) $(GLINK ClassAllocator) $(GLINK ClassDeallocator) ) Classes consist of: $(DL $(DT a super class) $(DT interfaces) $(DT dynamic fields) $(DT static fields) $(DT types) $(DT functions) $(DD $(DL $(DT static functions) $(DT dynamic functions) $(DT $(LINK2 #constructors, constructors)) $(DT $(LINK2 #destructors, destructors)) $(DT $(LINK2 #staticconstructor, static constructors)) $(DT $(LINK2 #staticdestructor, static destructors)) $(DT $(LINK2 #invariants, invariants)) $(DT $(LINK2 #unittest, unit tests)) $(DT $(LINK2 #allocators, allocators)) $(DT $(LINK2 #deallocators, deallocators)) ) ) ) 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; ------
The D compiler is free to rearrange the order of fields in a class to optimally pack them in an implementation-defined manner. 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.
Constructors are defined with a function name of $(B this) and having no return value: ------ class Foo { $(B this)(int x) // declare constructor for Foo { ... } $(B this)() { ... } } ------ Base class construction is done by calling the base class constructor by the name $(B super): ------ class A { this(int y) { } } class B : A { int j; this() { ... $(B super)(3); // call base constructor A.this(3) ... } } ------ Constructors can also call other constructors for the same class in order to share common initializations: ------ class C { int j; this() { ... } this(int i) { $(B this)(); j = i; } } ------ If no call to constructors via $(B this) or $(B super) appear in a constructor, and the base class has a constructor, a call to $(B super)() is inserted at the beginning of the constructor.
If there is no constructor for a class, but there is a constructor for the base class, a default constructor of the form: ------ this() { } ------ $(P is implicitly generated.) $(P Class object construction is very flexible, but some restrictions apply:) $(OL $(LI It is illegal for constructors to mutually call each other: ------ this() { this(1); } this(int i) { this(); } // illegal, cyclic constructor calls ------ ) $(LI If any constructor call appears inside a constructor, any path through the constructor must make exactly one constructor call: ------ this() { a || super(); } // illegal this() { (a) ? this(1) : super(); } // ok this() { for (...) { super(); // illegal, inside loop } } ------ ) $(LI It is illegal to refer to $(B this) implicitly or explicitly prior to making a constructor call.) $(LI Constructor calls cannot appear after labels (in order to make it easy to check for the previous conditions in the presence of goto's).) ) $(P Instances of class objects are created with $(I NewExpression)s:) ------ A a = new A(3); ------ $(P The following steps happen:) $(OL $(LI Storage is allocated for the object. If this fails, rather than return $(B null), an $(B OutOfMemoryException) is thrown. Thus, tedious checks for null references are unnecessary. ) $(LI The raw data is statically initialized using the values provided in the class definition. The pointer to the vtbl[] (the array of pointers to virtual functions) is assigned. This ensures that constructors are passed fully formed objects for which virtual functions can be called. This operation is equivalent to doing a memory copy 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. ) $(LI If there is a constructor defined for the class, the constructor matching the argument list is called. ) $(LI If class invariant checking is turned on, the class invariant is called at the end of the constructor. ) )
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.
When the garbage collector calls a destructor for an object of a class that has members that are references to garbage collected objects, those references are no longer valid. This means that destructors cannot reference sub objects. This is because that the garbage collector does not collect objects in any guaranteed order, so there is no guarantee that any pointers or references to any other garbage collected objects exist when the garbage collector runs the destructor for an object. This rule does not apply to auto objects or objects deleted with the $(I DeleteExpression), as the destructor is not being run by the garbage collector, meaning all references are valid.
The garbage collector is not guaranteed to run the destructor for all unreferenced objects. Furthermore, the order in which the garbage collector calls destructors for unreference objects is not specified.
Objects referenced from the data segment never get collected by the gc.
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 $(TT 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 $(B static this)() // static constructor { a = b + 1; // a is set to 2 b = a * 2; // b is set to 4 } } ------ $(TT static this()) is called by the startup code before $(TT main()) is called. If it returns normally (does not throw an exception), the static destructor is added to the list of functions to be called on program termination. Static constructors have empty parameter lists.
Static constructors within a module are executed in the lexical order in which they appear. All the static constructors for modules that are directly or indirectly imported are executed before the static constructors for the importer.
The $(B static) in the static constructor declaration is not an attribute, it must appear immediately before the $(B this): ------ class Foo { static this() { ... } // a static constructor static private this() { ... } // not a static constructor static { this() { ... } // not a static constructor } static: this() { ... } // not a static constructor } ------
The $(B static) in the static destructor declaration is not an attribute, it must appear immediately before the $(B ~this): ------ class Foo { static ~this() { ... } // a static destructor static private ~this() { ... } // not a static destructor static { ~this() { ... } // not a static destructor } static: ~this() { ... } // not a static destructor } ------
assert()
expression, as:
------
Date mydate;
...
assert(mydate); // check that class Date invariant holds
------
Invariants contain assert expressions, and so when they fail,
they throw a $(TT AssertError)s.
Class invariants are inherited, that is,
any class invariant is implicitly anded with the invariants of its base
classes.
There can be only one $(I Invariant) per class.
When compiling for release, the invariant code is not generated, and the compiled program runs at maximum speed.
Classes can have a special member function called: ------ unittest { ...test code... } ------ A compiler switch, such as $(B -unittest) for $(B dmd), will cause the unittest test code to be compiled and incorporated into the resulting executable. The unittest code gets run after static initialization is run and before the $(TT main()) function is called.
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 { Sum sum = new Sum; assert(sum.add(3,4) == 7); assert(sum.add(-2,0) == -2); } } ------
An scope class reference can only appear as a function local variable. It must be declared as being $(B scope): ------ scope class Foo { ... } void func() { Foo f; // error, reference to scope class must be scope scope Foo g = new Foo(); // correct } ------ When an scope class reference goes out of scope, the destructor (if any) for it is automatically called. This holds true even if the scope was exited via a thrown exception.
When a non-static nested class is instantiated, the context pointer is assigned before the class's constructor is called, therefore the constructor has full access to the enclosing variables. A non-static nested class can only be instantiated when the necessary context pointer information is available: ------ class Outer { class Inner { } static class SInner { } } void func() { class Nested { } Outer o = new Outer; // Ok Outer.Inner oi = new Outer.Inner; // Error, no 'this' for Outer Outer.SInner os = new Outer.SInner; // Ok Nested n = new Nested; // Ok } ------ While a non-static nested class can access the stack variables of its enclosing function, that access becomes invalid once the enclosing function exits: ------ class Base { int foo() { return 1; } } Base func() { int m = 3; class Nested : Base { int foo() { return m; } } Base b = new Nested; assert(b.foo() == 3); // Ok, func() is still active return b; } int test() { Base b = func(); return b.foo(); // Error, func().m is undefined } ------ If this kind of functionality is needed, the way to make it work is to make copies of the needed variables within the nested class's constructor: ------ class Base { int foo() { return 1; } } Base func() { int m = 3; class Nested : Base { int m_; this() { m_ = m; } int foo() { return m_; } } Base b = new Nested; assert(b.foo() == 3); // Ok, func() is still active return b; } int test() { Base b = func(); return b.foo(); // Ok, using cached copy of func().m } ------ $(P A $(I this) can be supplied to the creation of an inner class instance by prefixing it to the $(I NewExpression): ) --------- class Outer { int a; class Inner { int foo() { return a; } } } int bar() { Outer o = new Outer; o.a = 3; Outer.Inner oi = $(B o).new Inner; return oi.foo(); // returns 3 } --------- $(P Here $(B o) supplies the $(I this) to the outer class instance of $(B Outer). ) $(P The property $(B .outer) used in a nested class gives the $(B this) pointer to its enclosing class. If the enclosing context is not a class, the $(B .outer) will give the pointer to it as a $(B void*) type. ) ---- class Outer { class Inner { Outer foo() { return this.$(B outer); } } void bar() { Inner i = new Inner; assert(this == i.foo()); } } void test() { Outer o = new Outer; o.bar(); } ----