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 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.
What’s my runtime?
For a while now, D has had predefined version identifiers for user code to detect the C runtime implementation at compile time. These are:
CRuntime_BionicCRuntime_DigitalMarsCRuntime_GlibcCRuntime_MicrosoftCRuntime_MuslCRuntime_UClibc
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:
CppRuntime_ClangCppRuntime_DigitalMarsCppRuntime_GccCppRuntime_MicrosoftCppRuntime_Sun
Why so much conflict?
C++ support also gets a new syntax for declaring C++ linkage, which affects how a symbol is mangled. Consider a C++ library, MyLib, which uses the namespace mylib. The original syntax for binding a function in that namespace looks like this:
/*
The original C++:
namespace mylib { void cppFunc(); }
*/
// The D declaration
extern(C++, mylib) void cppFunc();
This declares that cppFunc 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 . On the D side, the function can be referred to either as cppFunc or as mylib.cppFunc.
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. It’s natural to want to name the root package in D mylib, 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) declarations will not be compilable anywhere in the mylib package because the symbols conflict.
To alleviate the problem, an alternative syntax was proposed using strings to declare the namespaces in the linkage attribute, rather than identifiers:
/*
The original C++:
namespace foo { void cppFunc(); }
*/
// The D declaration
extern(C++, "foo") void cppFunc();
With this syntax, no mylib 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.
New compile-time things
This release provides two new built-in traits for more compile-time reflection options. Like all built-in traits, they are accessible via the __traits expression. There’s also a new pragma that lets you bring some linker options into the source code in a very specific circumstance.
Are you a zero?
isZeroInit can be used to determine if the default initializer of a given type is 0, or more specifically, it evaluates to true if all of the init value’s bits are zero. The example below uses compile-time asserts to verify the zeroness and nonzeroness of a few default init values, but I’ve saved a version that prints the results at runtime, for more immediate feedback, and can be compiled and run from the browser.
struct ImaZero {
int x;
}
struct ImaNonZero {
int x = 10;
}
// double.init == double.nan
static assert(!__traits(isZeroInit, double));
// int.init == 0
static assert(__traits(isZeroInit, int));
// ImaZero.init == ImaZero(0)
static assert(__traits(isZeroInit, ImaZero));
// ImaNonZeror.init == ImaZero(10)
static assert(!__traits(isZeroInit, ImaNonZero));
Computer, query target.
The second new trait is getTargetInfo, which allows compile-time queries about the target platform. The argument is a string that serves as a key, and the result is “an expression describing the requested target information”. Currently supported strings are “cppRuntimeLibrary”, “floatAbi”, and “ObjectFormat”.
The following prints all three at compile time.
pragma(msg, __traits(getTargetInfo, "cppRuntimeLibrary")); pragma(msg, __traits(getTargetInfo, "floatAbi")); pragma(msg, __traits(getTargetInfo, "objectFormat"));
On Windows, using the default (-m32) DigitalMars toolchain, I see this:
snn hard omf
With the Microsoft Build Tools (via VS 2017), compiling with -m64 and -m32mscoff, I see this:
libcmt hard coff
Yo! Linker! Take care of this, will ya?
D has long supported a lib 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’s a new pragma in town that let’s the programmer specify specific linker commands in source code and behaves rather differently. Meet the linkerDirective pragma:
pragma(linkerDirective, "/FAILIFMISMATCH:_ITERATOR_DEBUG_LEVEL=2");
The behavior is specified as “Implementation Defined”. The current implementation is specced to behave like so:
- The string literal specifies a linker directive to be embedded in the generated object file.
- Linker directives are only supported for MS-COFF output.
Just to make sure you didn’t 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 -m64 or -m32mscoff. And some say the D community doesn’t care about Windows!
Of course there’s more!
The above are just a few cherries I picked from the list. For a deeper dive, see the full changelog. And head over to the Downloads page to get the installer for your platform. It looks a lot nicer than the boring list of files linked in the changelog.
