![\"\"](\"http:\/\/dlang.org\/blog\/wp-content\/uploads\/2016\/08\/d6.png\")
<\/p>\n<\/p>\n
Another major release of DMD, this time 2.078.0, has been packaged and delivered in time for the new year. See the full changelog at dlang.org<\/a> and download the compiler for your platform either from the main download<\/a> page or the 2.078.0 release directory<\/a>.<\/p>\n This release brings a number of quality-of-life improvements, fixing some minor annoyances and inconsistencies, three of which are targeted at smoothing out the experience of programming in D without DRuntime.<\/p>\n D has included static constructors and destructors<\/a>, both as aggregate type members and at module level, for most of its existence. The former are called in lexical order as DRuntime goes through its initialization routine, and the latter are called in reverse lexical order as the runtime shuts down. But when programming in an environment without DRuntime, such as when using the DMD 2.078.0 brings static module construction and destruction to those environments in the form of two new pragmas<\/a>, crun1.d<\/strong><\/p>\n The compiler requires that any function annotated with the new pragmas be declared with the In a normal D program, the C When a D module\u2019s The example above is intended to clearly show that the crun2.d<\/strong><\/p>\n The difference is that the C You may discover that One of the limitations in destruct.d<\/strong><\/p>\n Interestingly, this is implemented in terms of cleanup1.d<\/strong><\/p>\n Since D\u2019s cleanup2.d<\/strong><\/p>\n Note that exceptions are not implemented for One of the seemingly obscure features dependent upon DRuntime is the DMD 2.078.0 changes things up<\/a>. The compiler is aware of the presence of the runtime implementation at compile time, so it can see whether or not the current implementation provides a New users of DMD on Windows will now have an easier time getting a 64-bit environment set up. It\u2019s still necessary to install the Microsoft build tools<\/a>, but now DMD will detect the installation<\/a> of either the Microsoft Build Tools package or Visual Studio at runtime when either DRuntime has been enhanced to allow more fine-grained control over unit tests. Of particular note is the This is the first DMD release of 2018. We can\u2019t wait to see what the next 12 months bring for the D programming language community. From everyone at the D Language Foundation, we hope you have a very Happy New Year!<\/p>\n","protected":false},"excerpt":{"rendered":" Another major release of DMD, this time 2.078.0, has been packaged and delivered in time for the new year. This release brings a number of quality-of-life improvements, fixing some minor annoyances and inconsistencies, three of which are targeted at smoothing out the experience of programming in D without DRuntime.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[26,12,8,27,4],"tags":[],"_links":{"self":[{"href":"https:\/\/dlang.org\/blog\/wp-json\/wp\/v2\/posts\/1294"}],"collection":[{"href":"https:\/\/dlang.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/dlang.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/dlang.org\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/dlang.org\/blog\/wp-json\/wp\/v2\/comments?post=1294"}],"version-history":[{"count":13,"href":"https:\/\/dlang.org\/blog\/wp-json\/wp\/v2\/posts\/1294\/revisions"}],"predecessor-version":[{"id":1365,"href":"https:\/\/dlang.org\/blog\/wp-json\/wp\/v2\/posts\/1294\/revisions\/1365"}],"wp:attachment":[{"href":"https:\/\/dlang.org\/blog\/wp-json\/wp\/v2\/media?parent=1294"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/dlang.org\/blog\/wp-json\/wp\/v2\/categories?post=1294"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/dlang.org\/blog\/wp-json\/wp\/v2\/tags?post=1294"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}C runtime construction and destruction<\/h3>\n
-betterC<\/code> compiler switch<\/a>, or using a stubbed-out runtime, static construction and destruction are not available.<\/p>\npragma(crt_constructor)<\/code> and pragma(crt_destructor)<\/code> respectively. The former causes any function to which it\u2019s applied to be executed before the C main<\/code>, and the latter after the C main<\/code>, as in this example:<\/p>\n\/\/ Compile with: dmd crun1.d\r\n\/\/ Alternatively: dmd -betterC crun1.d\r\n\r\nimport core.stdc.stdio;\r\n\r\n\/\/ Each of the following functions should have\r\n\/\/ C linkage (cdecl).\r\nextern(C):\r\n\r\npragma(crt_constructor)\r\nvoid init()\r\n{\r\n puts(\"init\");\r\n}\r\n\r\npragma(crt_destructor)\r\nvoid fini()\r\n{\r\n puts(\"fini\");\r\n}\r\n\r\nvoid main()\r\n{\r\n puts(\"C main\");\r\n}<\/pre>\nextern(C)<\/code> linkage attribute<\/a>. In this example, though it isn\u2019t required, main<\/code> is also declared as extern(C)<\/code>. The colon syntax on line 8 applies the attribute to every function that follows, up to the end of the module or until a new linkage attribute appears.<\/p>\nmain<\/code> is the entry point for DRuntime and is generated by the compiler. When the C runtime calls the C main<\/code>, the D runtime does its initialization, which includes starting up the GC, executing static constructors, gathering command-line arguments into a string array, and calling the application\u2019s main<\/code> function, a.k.a. D main<\/code>.<\/p>\nmain<\/code> is annotated with extern(C)<\/code>, it essentially replaces DRuntime\u2019s implementation, as the compiler will never generate a C main<\/code> function for the runtime in that case. If -betterC<\/code> is not supplied on the command line, or an alternative implementation is not provided, DRuntime itself is still available and can be manually initialized and terminated.<\/p>\ncrt_constructor<\/code> pragma will cause init<\/code> to execute before the C main<\/code> and the crt_destructor<\/code> causes fini<\/code> to run after. This introduces new options for scenarios where DRuntime is unavailable. However, take away the extern(C)<\/code> from main<\/code> and the same execution order will print to the command line:<\/p>\n\/\/ Compile with: dmd crun2.d\r\n\r\nimport core.stdc.stdio;\r\n\r\npragma(crt_constructor)\r\nextern(C) void init()\r\n{\r\n puts(\"init\");\r\n}\r\n\r\npragma(crt_destructor)\r\nextern(C) void fini()\r\n{\r\n puts(\"fini\");\r\n}\r\n\r\nvoid main()\r\n{\r\n import std.stdio : writeln;\r\n writeln(\"D main\");\r\n}<\/pre>\nmain<\/code> now belongs to DRuntime and our main is the D main<\/code>. The execution order is: init<\/code>, C main<\/code>, D main<\/code>, fini<\/code>. This means init<\/code> is effectively called before DRuntime is initialized and fini<\/code> after it terminates. Because this example uses the DRuntime function writeln<\/code>, it can\u2019t be compiled with -betterC<\/code>.<\/p>\nwriteln<\/code> works if you import it at the top of the module and substitute it for puts<\/code> in the example. However, always remember that even though DRuntime may be available, it\u2019s not in a valid state when a crt_constructor<\/code> and a crt_destructor<\/code> are executed.<\/p>\nRAII for
-betterC<\/code><\/h3>\n-betterC<\/code> mode has been the absence of RAII. In normal D code, struct<\/code> destructors are executed when an instance goes out of scope. This has always depended on DRuntime, and since the runtime isn\u2019t available in -betterC<\/code> mode, neither are struct<\/code> destructors. With DMD 2.078.0, the are<\/em> in the preceding sentence becomes were<\/em><\/a>.<\/p>\n\/\/ Compile with: dmd -betterC destruct.d\r\n\r\nimport core.stdc.stdio : puts;\r\n\r\nstruct DestroyMe\r\n{\r\n ~this()\r\n {\r\n puts(\"Destruction complete.\");\r\n }\r\n}\r\n\r\nextern(C) void main()\r\n{\r\n DestroyMe d;\r\n}<\/pre>\ntry..finally<\/code>, so a side-effect is that -betterC<\/code> mode now supports try<\/code> and finally<\/code> blocks:<\/p>\n\/\/ Compile with: dmd -betterC cleanup1.d\r\n\r\nimport core.stdc.stdlib,\r\n core.stdc.stdio;\r\n\r\nextern(C) void main()\r\n{\r\n int* ints;\r\n try\r\n {\r\n \/\/ acquire resources here\r\n ints = cast(int*)malloc(int.sizeof * 10);\r\n puts(\"Allocated!\");\r\n }\r\n finally\r\n {\r\n \/\/ release resources here\r\n free(ints);\r\n puts(\"Freed!\");\r\n }\r\n}<\/pre>\nscope(exit)<\/code> feature<\/a> is also implemented in terms of try..finally<\/code>, this is now possible in -betterC<\/code> mode also:<\/p>\n\/\/ Compile with: dmd -betterC cleanup2.d\r\n\r\nimport core.stdc.stdlib,\r\n core.stdc.stdio;\r\n\r\nextern(C) void main()\r\n{\r\n auto ints1 = cast(int*)malloc(int.sizeof * 10);\r\n scope(exit)\r\n {\r\n puts(\"Freeing ints1!\");\r\n free(ints1);\r\n }\r\n\r\n auto ints2 = cast(int*)malloc(int.sizeof * 10);\r\n scope(exit)\r\n {\r\n puts(\"Freeing ints2!\");\r\n free(ints2);\r\n }\r\n}<\/pre>\n-betterC<\/code> mode, so there\u2019s no catch<\/code>, scope(success)<\/code>, or scope(failure)<\/code>.<\/p>\nOptional
ModuleInfo<\/code><\/h3>\nModuleInfo<\/code> type<\/a>. It\u2019s a type that works quietly behind the scenes as one of the enabling mechanisms of reflection and most D programmers will likely never hear of it. That is, unless they start trying to stub out their own minimal runtime. That\u2019s when linker errors start cropping up complaining about the missing ModuleInfo<\/code> type, since the compiler will have generated an instance of it for each module in the program.<\/p>\nModuleInfo<\/code> declaration. If it does, instances will be generated as appropriate. If it doesn\u2019t, then the instances won\u2019t be generated. This makes it just that much easier to stub out your own runtime, which is something you\u2019d want to do if you were, say, writing a kernel in D<\/a>.<\/p>\nOther notable changes<\/h3>\n
-m64<\/code> or -m32mscoff<\/code> is specified on the command line. Previously, configuration was handled automatically only by the installer; manual installs had to be configured manually.<\/p>\n--DRT-testmode<\/code> flag which can be passed to any D executable. With the argument \"run-main\"<\/code>, the current default, any unit tests present will be run and then main<\/code> will execute if they all pass; with \"test-or-main\"<\/code>, the planned default beginning with DMD 2.080.0, any unit tests present will run and the program will exit with a summary of the results, otherwise main<\/code> will execute; with \"test-only\"<\/code>, main<\/code> will not be executed, but test results will still be summarized if present.<\/p>\nOnward into 2018<\/h3>\n