![\"\"](\"http:\/\/dlang.org\/blog\/wp-content\/uploads\/2016\/08\/d6.png\")
<\/p>\n<\/p>\n
Version 2.083.0 of DMD, the D reference compiler, is ready for download<\/a>. The changelog lists 47 fixes and enhancements<\/a> across all components of the release package. Notable among them are some C++ compatibility enhancements and some compile-time love.<\/p>\n D’s support for linking to C++ binaries has been evolving and improving with nearly every release. This time, the new things aren’t very dramatic, but still very welcome to those who work with both C++ and D in the same code base.<\/p>\n For a while now, D has had predefined version identifiers<\/a> for user code to detect the C runtime implementation at compile time. These are:<\/p>\n These aren’t reliable when linking against C++ code. Where the C runtime in use often depends on the system, the C++ runtime is compiler-specific. To remedy that, 2.083.0 introduces a few new predefined versions<\/a>:<\/p>\n C++ support also gets a new syntax for declaring C++ linkage<\/a>, which affects how a symbol is mangled<\/a>. Consider a C++ library, MyLib, which uses the namespace This declares that In practice, this approach creates opportunities for conflict when a namespace is the same as a D keyword. It also has an impact on how one approaches the organization of a binding.\u00a0 It\u2019s natural to want to name the root package in D To alleviate the problem, an alternative syntax was proposed using strings to declare the namespaces in the linkage attribute, rather than identifiers:<\/p>\n With this syntax, no This release provides two new built-in traits for more compile-time reflection options. Like all built-in traits<\/a>, they are accessible via the The second new trait is The following prints all three at compile time.<\/p>\n On Windows, using the default ( With the Microsoft Build Tools (via VS 2017), compiling with D has long supported a The behavior is specified as \u201cImplementation Defined\u201d. The current implementation is specced to behave like so:<\/p>\n Just to make sure you didn\u2019t gloss over the first list item, look at it again. The linker directive is not passed by the compiler to the linker, but emitted to the object file. Since it is only supported for MS-COFF, that means its only a thing for folks on Windows when they are compiling with The above are just a few cherries I picked from the list. For a deeper dive, see the full changelog<\/a>. And head over to the Downloads<\/a> page to get the installer for your platform. It looks a lot nicer than the boring list of files linked in the changelog<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":" Version 2.083.0 of DMD, the D reference compiler, is ready for download. The changelog lists 47 fixes and enhancements across all components of the release package. Notable among them are some C++ compatibility enhancements and some compile-time love. C++ compatibility D’s support for linking to C++ binaries has been evolving and improving with nearly every […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[26,12,27],"tags":[],"_links":{"self":[{"href":"https:\/\/dlang.org\/blog\/wp-json\/wp\/v2\/posts\/1748"}],"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=1748"}],"version-history":[{"count":21,"href":"https:\/\/dlang.org\/blog\/wp-json\/wp\/v2\/posts\/1748\/revisions"}],"predecessor-version":[{"id":1769,"href":"https:\/\/dlang.org\/blog\/wp-json\/wp\/v2\/posts\/1748\/revisions\/1769"}],"wp:attachment":[{"href":"https:\/\/dlang.org\/blog\/wp-json\/wp\/v2\/media?parent=1748"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/dlang.org\/blog\/wp-json\/wp\/v2\/categories?post=1748"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/dlang.org\/blog\/wp-json\/wp\/v2\/tags?post=1748"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}C++ compatibility<\/h2>\n
What’s my runtime?<\/h3>\n
\n
CRuntime_Bionic<\/code><\/li>\nCRuntime_DigitalMars<\/code><\/li>\nCRuntime_Glibc<\/code><\/li>\nCRuntime_Microsoft<\/code><\/li>\nCRuntime_Musl<\/code><\/li>\nCRuntime_UClibc<\/code><\/li>\n<\/ul>\n\n
CppRuntime_Clang<\/code><\/li>\nCppRuntime_DigitalMars<\/code><\/li>\nCppRuntime_Gcc<\/code><\/li>\nCppRuntime_Microsoft<\/code><\/li>\nCppRuntime_Sun<\/code><\/li>\n<\/ul>\nWhy so much conflict?<\/h3>\n
mylib<\/code>. The original syntax for binding a function in that namespace looks like this:<\/p>\n\/*\r\n The original C++:\r\n namespace mylib { void cppFunc(); }\r\n*\/\r\n\/\/ The D declaration\r\nextern(C++, mylib) void cppFunc();<\/pre>\ncppFunc<\/code> has C++ linkage (the symbol is mangled in a manner specific to the C++ compiler) and that the symbol belongs to the C++ namespace mylib<\/code>\u00a0<\/a>. On the D side, the function can be referred to either as cppFunc<\/code> or as mylib.cppFunc<\/code>.<\/p>\nmylib<\/code>, as it matches the library name and it is a D convention to name modules and packages using lowercase. In that case, extern(C++, mylib)<\/code> declarations will not be compilable anywhere in the mylib<\/code> package because the symbols conflict.<\/p>\n\/*\r\n The original C++:\r\n namespace foo { void cppFunc(); }\r\n*\/\r\n\/\/ The D declaration\r\nextern(C++, \"foo\") void cppFunc();<\/pre>\nmylib<\/code> symbol is created on the D side; it is used solely for name mangling. No more conflicts with keywords, and D packages can be used to match the C++ namespaces on the D side. The old syntax isn’t going away anytime soon, though.<\/p>\nNew compile-time things<\/h2>\n
__traits<\/code> expression. There\u2019s also a new pragma<\/code> that lets you bring some linker options into the source code in a very specific circumstance.<\/p>\nAre you a zero?<\/h3>\n
isZeroInit<\/code> can be used to determine if the default initializer of a given type<\/a> is 0<\/code>, or more specifically, it evaluates to true<\/code> if all of the init value\u2019s bits are zero<\/a>. The example below uses compile-time asserts to verify the zeroness and nonzeroness of a few default init values, but I\u2019ve saved a version that prints the results at runtime, for more immediate feedback, and can be compiled and run from the browser<\/a>.<\/p>\nstruct ImaZero {\r\n int x;\r\n}\r\n\r\nstruct ImaNonZero {\r\n int x = 10;\r\n}\r\n\r\n\/\/ double.init == double.nan\r\nstatic assert(!__traits(isZeroInit, double));\r\n\r\n\/\/ int.init == 0\r\nstatic assert(__traits(isZeroInit, int));\r\n\r\n\/\/ ImaZero.init == ImaZero(0)\r\nstatic assert(__traits(isZeroInit, ImaZero));\r\n\r\n\/\/ ImaNonZeror.init == ImaZero(10)\r\nstatic assert(!__traits(isZeroInit, ImaNonZero));<\/pre>\nComputer, query target.<\/h3>\n
getTargetInfo<\/code><\/a>, which allows compile-time queries about the target platform. The argument is a string that serves as a key, and the result is \u201can expression describing the requested target information\u201d. Currently supported strings are \u201ccppRuntimeLibrary\u201d<\/code>, \u201cfloatAbi\u201d<\/code>, and \u201cObjectFormat\u201d<\/code>.<\/p>\npragma(msg, __traits(getTargetInfo, \"cppRuntimeLibrary\"));\r\npragma(msg, __traits(getTargetInfo, \"floatAbi\"));\r\npragma(msg, __traits(getTargetInfo, \"objectFormat\"));<\/pre>\n
-m32<\/code>) DigitalMars toolchain, I see this:<\/p>\nsnn\r\nhard\r\nomf<\/pre>\n
-m64<\/code> and -m32mscoff<\/code>, I see this:<\/p>\nlibcmt\r\nhard\r\ncoff<\/pre>\n
Yo! Linker! Take care of this, will ya?<\/h3>\n
lib<\/code> pragma, allowing programmers to tell the compiler to pass a given library to the linker in source code rather than on the command line. Now, there\u2019s a new pragma in town that let\u2019s the programmer specify specific linker commands in source code and behaves rather differently. Meet the linkerDirective<\/code> pragma<\/a>:<\/p>\npragma(linkerDirective, \"\/FAILIFMISMATCH:_ITERATOR_DEBUG_LEVEL=2\");<\/pre>\n
\n
-m64<\/code> or -m32mscoff<\/code>. And some say the D community doesn\u2019t care about Windows!<\/p>\nOf course there\u2019s more!<\/h2>\n