Group 14 Muazam Ali Anil Ozdemir D Programming Language
Introduction and Why D? It doesn t come with a religion this is written somewhere along the overview of D programming language. If you actually take the time to look how things are done in D you can see this line tells a lot for this programming language such that, it is multi paradigm so that it s aim is to take good features of every paradigm. So you don t have to choose one in D. You can use imperative, object oriented, generic and even functional paradigms. The main objective is written as practical language for practical programmers who need to get the job done quickly, reliably, and leave behind maintainable, easy to understand code. One can easily notice that D is trying to make it easier on programmer as much as possible with intuitive approaches to features taken from many other paradigms. So whatever you want to do and however you want to do, D aims to let you do it without getting your way too much while trying to minimize common mistakes as much as possible. These terms might seem a bit unclear and too idealistic at first but D argues that convenience and efficiency are not necessarily mutually exclusive. For example in D all variables are initialized unless you don t want them to ( via void ), array usage is intuitive and easy, overloading is simple, iteration is clean,you can use NaN etc. When we are talking about new languages it is usually the case that we start by comparisons with an existing language. D is mostly established over C/C++ to the point that entire C is available without any interface, however D argues that you would never need to do so because of D s own features that are more powerful, safer and efficient. One of the goals of D is listed as Where D code looks the same as C code, have it either behave the same or issue an error. [1] However while doing this it is also argued that C++ while being powerful and efficient is also being held back by the necessity of being compatible with C. So the question becomes can we become, while being powerful and efficient like C++ and also keep it simple and practical to use. There are many design goals for D however the most important point of them all would be listed as Whenever a conflict in design happens, resolution will be in favor of usability. Object Oriented D You have structs and classes in D, structs are meant for value types and classes are for encapsulation, inheritance, polymorphism. Every class has its root as class Object. Multiple inheritance is not supported due to the problems and complexity it brings isn t really worth instead Java style interfaces. Classes has lots of flexibility, you can access them and their fields( values) in many ways, in contrast to C++ you can define classes and function in the same file, where in C++ you have to make a header and an implementation file redefining the same functions. These approaches lines pretty good with the goals we mentioned before, keeping the power and also making it simple to use and not having a hard time for coder. One feature is to access in terms of byte with keyword offset another is to access the fields ( excluding the hidden ones ) by tupleof keyword.
Functional D D supports immutability as well, you can define a data immutable so it will never ever change. However we still don t want to give up the conventional functionality that comes with mutation, so D tries to combine them both in a smooth way. This sets the foundation of true parallel programming as in D if you are in immutable territory you have the guarantee that correctly typed program can t change immutable data. Also it works such that if you are in immutable territory and follow a reference, you are guaranteed to end up in immutable territory. We mentioned parallel programming before so why immutable data is awesome, it is because in terms of synchronization. It is usually the case(in other programming languages) that system doesn t know which data should be shared and which isn t so the burden is always on programmer however D says that every memory is private unless specified as shared. So with shared qualifier data will be visible to multiple threads at once. System therefore knows which data is shared and which is not and can take proper steps for synchronization. Now combined with immutable data, we can say the best synchronization is no synchronization since sharing immutable data around needs no such thing as synchronization. These all come together in D as long as the immutability holds. [2] SafeD World One interesting area of D programming language is the SafeD where there is no possible way to have a memory corruption. Are you sick of dealing with C s way of handling pointers or counting mallocs/free s. D offers a world for you to safely and securely write your code without dealing with any of those. When you enter SafeD you leave pointers unchecked casts behind. The most important promise would be your code if compiles, it most of the time works, which of course also depends on your definition of work but the point is there is no undefined behaviours. Where like in C issue with dangling pointers and such as you can guess can and will result in undefined behaviour if dereferenced. Garbage Collection in D Considering the approach D has with all other things it shouldn t be hard to guess which way they took in garbage collection. You don t have to deal with garbage collection in D by default just allocate and later on garbage collector will return all unused memory however you still have the flexibility to specify where you don t want garbage collector get involved. There are basically two types of pointers in D those who reference to garbage collected memory and those do not which is basically C type of pointers so for these anything you can do in C is also legal in D. However there are still some restrictions such that you can t cast them etc. to keep the flexibility of garbage collector design.
Error Handling Error handling in D is quite straightforward but before going into that lets look at other languages way of handling like C. C way of handling errors, detecting and reporting them isn t really consistent and varies. So basically to deal with each situation(error) there needs to be a code for detecting and reporting as well. Eventually as it builds up this error handling code can even get error prone as well. D s way of handling errors starts with some assumptions that basically states that errors are not planned part of the program which means they are exceptions and unexpected hence the error handling code does not have to be performance critical. All errors are objects that are derived from Error class where it contains a function tostring which produces a text for human to read. It is quite straightforward in the sense that if the error is out of memory then it displays Out of Memory so as we mentioned even if this process, exception handling stack unwinding is a relatively slow, we don t really care since we know it is not the normal flow of the program it is an error. Since normal flow does not have to check for errors for every function, it can be realistically faster to use exception handling for errors. Templates/Generic Programming in D Templates in D is quite similar to C++ however there are few differences and added features I would say to make it more flexible or more expressive. One example is a template instantiation can be aliased such that : Example taken from http://dlang.org/: template TFoo(T) { alias t = T*; } alias abc = TFoo!( int ); abc.t x; // declare x to be of type int Template arguments can be implicitly converted and will refer to the same type so that TFoo!(3) will be equal to TFoo!(3u) since 3u will be converted to 3 to match int. Alias parameters enable templates to be parameterized with and type of global name, local name, module name etc. So it offers quite a lot flexibility. You can also use nested templates and recursive templates. In General In overall we can pretty much say D tries to add to the functionalities and practicality of C++ by the lessons learned from its practical usage. It implements design by contract, lazy evaluation and compile time execution and has redefined template syntax. It still has C s ability
to do low level stuff however also offers lots of functionality so that you wouldn t normally need them. Improves string manipulation of C/C++ by improving array handling. However there are still areas where D comes short, firstly comes to mind is lack of tools support. Also I would see D as a still growing and adapting language as it has many paradigms and tries to keep better features of them all so it is not by any sense a complete language. Even if it is compared mostly to C and really comparable to C, D is not for legacy since it needs modifications to the C code to run. Sources: [1] : http://dlang.org/overview.html [2] :The Case for D Andrei Alexandrescu http://www.drdobbs.com/parallel/the case for d/217801225?pgno=2 [3] : http://wiki.dlang.org/