This Week in D October 4, 2015

Welcome to This Week in D! Each week, we'll summarize what's been going on in the D community and write brief advice columns to help you get the most out of the D Programming Language.

The D Programming Language is a general purpose programming language that offers modern convenience, modeling power, and native efficiency with a familiar C-style syntax.

This Week in D has an RSS feed.

This Week in D is edited by Adam D. Ruppe. Contact me with any questions, comments, or contributions.

Statistics

Major Changes

CyberShadow and I made huge progress in including full Win32 bindings into druntime. I finally got the tests passing on my pull request after nine months of fighting with the Win64 Phobos build process, and CyberShadow is taking it to the next step with his own pull request which fixes several bugs he found in mine.

While the whole Windows API has always been available from D, you used to need to declare some of the prototypes yourself or use a third party binding, which could cause name clashes. These recent steps will make it more than just possible, they will make it very easy.

With both of us working on it, we hope to have these full bindings in the next major dmd release.

Speaking of Windows, dmd has a little-known switch, -m32mscoff, which generates Microsoft format object files and uses the MS linker even on 32 bit. (The default is to use Microsoft formats on 64 bit, but the older OMF format and Digital Mars' optlink linker on 32 bit, which causes some interop problems.) In the new version of dmd, there are mscoff Phobos libraries included, so the -m32mscoff switch will just work when building your own programs, if you have the Microsoft toolchain installed too.

Walter also changed the name of optlink's binary from link.exe to optlink.exe in the main distribution, which will help disambiguate PATH problems.

This is an exciting time for D's Windows users!

In the community

D Livestreamers

Live streaming is a favorite pastime of both developers and gamers. With many different streaming options available on how to stream, it can be a bit confusing.

With D there are currently two streamers:

This has introduced many people to the D programming language and it is hoped, will bring in more people as time goes on.

Community announcements

See more at digitalmars.D.announce.

Tip of the Week

This week's tip was written by Rikki Cattermole:

Interfaces: D headers and separating concerns of implementation

For the C/C++ converts, D has a very interesting feature. Or better put, lack of feature. Header files.

The purpose of header files is to distinguish between declarations and implementations of classes, structs and free functions.

Without focussing upon only this, there are other relevant aspects that must be considered. For example the D ABI mangles based upon the file. In C++ it is done based upon namespace instead. For C there is no name mangling.

Because of the change between C++ and D, with D mangling symbols to the file. It is not possible for symbols to be defined in other files while also declared (it's prototype) in another file. This is one of the core problems when considering what header files do. But this is not entirely true. It is possible to declare and implement functions and methods in separate files in D. It requires playing around with pragma(mangle, "_D....") on a symbol. There is an alternative and just as evil way.

Function/method prototypes, are functions/methods declared but without a body. Commonly will have the extern keyword attributed to it. This allows diverging the implementation to be provided to the linker instead of dmd. However keep in mind you will still need to implement it with the correct mangling for the symbol.

So far everything that has been said has not been idiomatic D. Not by far. A more idiomatic approach is to use D interface files or more commonly known as .di files. These files are an alternative to the regularly .d files. While they may have function/method bodies it is highly uncommon for symbols to contain it. Generally they will be generated by the compiler (-H).

While it is possible to write .di files manually, it is highly recommended against it. They are meant to accompany static/shared libraries. As a means to not give out your source code while making people able to include and use your code. They have quite a bit different purpose then C/C++ headers.

Generally if you are finding you are wanting to separate out implementation and declaration to share. You are probably doing something wrong. At least in the open source community.

Learn more about D

To learn more about D and what's happening in D: