D language Overview

D language Overview

Overview

What is language D?

D is a general system and application programming language. It is a more advanced language than C ++, while maintaining the ability to generate efficient code and directly access the operating system API and hardware. D is very suitable for writing various programs from a medium scale to those completed by the Team, millions of lines of code. D. Easy to learn. It provides programmers with a lot of convenience and applies various ambitious Compiler optimization technologies.

D is neither a scripting language nor an interpreted language. It does not require virtual machines, religion, or philosophy above all else. It is the actual language used by actual programmers. It helps programmers quickly and reliably complete easy-to-maintain and easy-to-understand code.

D is the accumulation of experience in implementing multi-language compilers for decades, and the accumulation of attempts to construct large-scale projects using those languages. D. get inspiration from those languages (mainly C ++) and tame it with experience and practicality in the real world. D man

Why is it d?

Indeed, why? Who needs another programming language?

The software industry has gone a long way since the C language was invented. Many new concepts are added to C ++, while maintaining backward compatibility with C, including compatibility with all weaknesses in the original design. There are many attempts to fix these vulnerabilities, but compatibility is the biggest problem. At the same time, C and C ++ are constantly introducing new features. These new features must be carefully added to the existing structure to avoid rewriting the old code. The final result is very complex-the c Standard has nearly 500 pages, and the C ++ standard has about 750 pages! C ++ implementation is both difficult and costly. The result is that there are differences between various implementations. Therefore, it is difficult to write c ++ code that can be completely transplanted.

C ++ programmers tend to use isolated islands of languages for programming. That is to say, they tend to be very proficient in a certain feature of a language and avoid using other features. Although the Code is usually portable between compilers, it is not that easy to transplant between programmers. One of the strengths of C ++ is that it supports many fundamentally different programming styles-but in the long run, repetitive and conflicting styles can impede development.

C ++ implements variable-size arrays and String concatenation in the standard library rather than in the language core. Not implementing these functions in the language core results in several unsatisfactory results.

Can I release and redesign C ++ capabilities and rewrite them into a simple, orthogonal, and practical language? Can this language be easily and correctly implemented, and enable the compiler to effectively generate highly optimized code?

The modern compiler technology has made great progress, some of the language features that were originally used as a supplement to the original compilation technology can be ignored (one such example is the 'register 'keyword in C language, A more subtle example is the macro Preprocessing Program in C ). We can rely on modern Compiler optimization technology rather than using language features (as the original compiler does) to achieve acceptable code quality.

D's main goal

* Adding proven features that increase productivity and adjust language features can avoid common but energy-consuming bugs and reduce software development costs by at least 10%.
* The code can be easily transplanted between compilers, machines, and operating systems.
* Supports multiple programming paradigms, that is, at least imperative, structured, object-oriented, and paradigm programming paradigms.
* For people familiar with C or C ++, the learning curve is short.
* Provide necessary low-level access capabilities.
* It is necessary to make D's compiler easy to implement (relative to C ++ ).
* It must be compatible with the binary interface of the Local C-language application.
* The syntax must be contextual.
* Provides convenient support for compiling international applications.
* Supports both contractual programming and unit test methodology.
* A lightweight and independent program can be built.

Features retained from C/C ++

Rough looks like C and C ++. In this way, it is easy to learn and transplant the code to D. It should be natural to switch from C/C ++ to D. Programmers do not have to start from scratch.

Using D does not mean that programmers will be strictly restricted to a running VM like Java or smalltalk. D. If there is no virtual machine, the compiler directly generates the target file that can be connected. D is directly connected to the operating system as C. Usually tools you are familiar with, such as make, are also suitable for D development.

* D retains the view of C/C ++ to a large extent. It uses the same algebraic syntax, the vast majority of the same expressions and statements, and the overall structure.
* D programs can adopt both C-style functions and data paradigms, C ++-style object-oriented paradigms, or a mixture of the two.
* The development model for compiling, linking, and debugging will be inherited, But compiling d into bytecode and then interpreting and executing it will not cause any problems.
* More and more experience in exception handling shows that exception handling is a more advanced error handling model than C's traditional "error code/Global errno variable" model.
* The runtime type recognition C ++ partially implements this function, while D goes further. The full support for runtime type recognition will make the garbage collection run better, make the debugger more functional, and make the support for automatic persistence better.
* D maintains compatibility with C call conventions. In this way, the program D can directly access the API of the operating system. The programmer's knowledge and experience on existing APIs and programming examples can continue to be used when using D, with little effort required.
* Operator overload D supports Operator overloading. In this way, you can use user-defined types to expand the type system consisting of basic types.
* Template templates are a method to implement model-based programming. Other methods include using macros or using covariant data types. Macro usage is outdated. The covariant type is direct, but inefficient and lacks the type check. The problem with C ++ templates is that they are too complex, the syntax of the same language is not harmonious, there are various types of conversion and heavy load rules, and so on. D provides a much simpler method to use templates.
* RaiI (resource acquisition or initialization) is one of the most important methods to compile reliable software.
* Down and dirty programming D retains the ability of down-and-dirty programming, rather than using external modules written in other languages. During system programming, you sometimes need to convert one pointer to another or use an assembly language. D's goal is not to avoid down and dirty programming, but to reduce their needs in general programming.

Discarded features

* Source Code compatibility with C. The source code-level compatibility extensions for C are available (C ++ and objective-C ). Further work in this area is subject to a large number of legacy code, and it is difficult to make significant improvements to the code.
* Connection compatibility with C ++. The object model of C ++ Runtime is too complex-if you want to better support it, basically it requires the D compiler to become a complete C ++ compiler.
* C Preprocessing Program. Macro processing is a simple method of extension language. It can add features that are not supported by some languages (invisible to the symbol debugger) to the language. Conditional compilation, the use of # include hierarchical text, macros, symbolic connections, etc., essentially constitute a fusion of the two languages that are difficult to distinguish, rather than a language. Worse, (perhaps the best), the C Preprocessing Program is a very primitive macro language. It's time to stop. Let's take a look at what the preprocessing program is used to do and design these features directly inside the language.
* Multiple inheritance. It is a complex feature with controversial values. It is difficult to implement it in an efficient way, and it is prone to various bugs when the compiler implements it. Almost all mi functions can be implemented by using a single inheritance plus interface and aggregation. The functions that only support Mi cannot compensate for its side effects.
* Namespace. When links are independently developed code, name conflicts may occur. namespace is an attempt to solve this problem. The concept of a module is simpler and works better.
* Mark the namespace. This is a bad feature of C. The structure tag name is located in a symbol table with different symbols. C ++ tries to merge and mark the namespace and the normal namespace, but it also needs to maintain backward compatibility with the legacy C code. The result is not printable.
* Forward Declaration. In terms of semantics, the C compiler only knows what is physically located before the current state. C ++ performs a little extension. The class members can depend on the class members declared after it. D. go further and get a reasonable conclusion that there is no need for the forward statement to exist. A function can be defined in a natural order, instead of using a common sequence from inside to out to avoid Forward Declaration like C.
* Contains files. One of the reasons for the slow compilation is that each compilation unit needs to re-parse a large number of header files. File inclusion should be imported to the symbol table.
* Create an object instance on the stack. In D, all classes are accessed through references. In this way, you do not need to copy constructor, value assignment operator, complex semantic analysis, and the interaction with Stack expansion in exception handling. Memory resources are released by the garbage collection program, and other resources are released by using the raiI feature of D.
* Three-byte code and two-byte code. Unicode is the future.
* Preprocessing Program. Modern languages do not need text processing. They should only need symbol processing.
* Non-virtual member functions. In C ++, the tired designers decide whether a function should be a virtual function. It is a common (and very difficult to find) Encoding Error to override a function in a subclass and update it to a virtual function in the parent class. It is more reliable to set all member functions as virtual functions and enable the compiler to determine whether a function has been overwritten and convert a function that has not been overwritten to a non-virtual function.
* A Bit Field of any length. Bit fields are complex, inefficient, and rarely used features.
* Supports 16-bit computers. D. Never consider using a mix of FAR/near pointers and all other 16-bit code mechanisms for claims. D language design assumes that the target machine has at least 32-bit flat memory space. D will be able to be transplanted to a 64-bit architecture without any difficulty.
* Dependencies on the number of compilation times. In C ++, a symbol table and various Preprocessing Program commands are required to successfully parse a source file. This makes it impossible to pre-parse the C ++ source code, and it is difficult to implement the process of compiling the code analysis program and the syntax-guided editor.
* Complexity of the compiler. By reducing the implementation complexity, multiple correct implementations are more likely to occur.
* The difference between '.' and '->. This difference is not necessary. The '.' operator can completely play the role of '->' in resolving pointer references.

D is suitable?

* Programmers who often use lint or similar code analysis tools to reduce bugs before compilation.
* Tune the warning level of the compiler to the highest level and those who tell the compiler to take the warning as an error.
* Programming department managers who have to rely on programming style specifications to avoid common C bugs.
* Identify the persons who cannot achieve the functions promised by C ++ object-oriented programming due to the complexity of C ++.
* People who indulge in C ++'s powerful expressiveness but are exhausted by explicit memory management and pointer search bugs.
* A project that requires a built-in test and verification mechanism.
* A team that develops a program with millions of lines.
* Programmers who believe that the language should provide sufficient features to avoid explicit pointer processing.
* A programmer who writes a numerical operation program. D has many features that directly support numerical computation. For example, it directly provides the plural type and Nan and infinity that have a definite behavior. (These are added to the latest c99 standard, but are not added to C ++ .)
* D's lexical analysis programs and parsing programs are completely independent from each other and independent from semantic analysis programs. This means that it is easy to write a simple tool to process D source code well without writing a complete compiler. This also means that the source code can pass a program that requires it in the form of a mark.

D is not suitable?

* In reality, no one will re-write a million-line C or C ++ program with D because D is not directly compatible with C/C ++ source code, D is not suitable for Legacy programs. (However, D provides good support for the legacy c api .)
* Very small programs-scripts or explanatory languages such as Python, dmdscript, or Perl are more suitable for this situation.
* As the first programming language, basic or Java is more suitable for beginners. For intermediate to advanced programmers, D is their second excellent language.
* Language purist. D is a practical language. Every feature of D serves this purpose. D is not a perfect language. For example, D can basically avoid using the structure and semantics of pointers in daily tasks. But d still supports pointers, because sometimes we need to break this rule. Similarly, d retains the type conversion because sometimes we need to override the type system.