h3r3tic

I suspect AMD's OpenCL driver uses very similar or the same headers. I opted for OpenGL because the subsequent experiments I'm doing interact with graphics, and require indirect dispatch.

It will definitely be useful for something more advanced, thanks! One feature I did not want was register allocation, as I needed full control over it. I figured it would be quicker to roll something custom than wrangle a complex piece of software to my needs.

I have just reworded the article to be slightly less verbally offensive. "Pervert" stays (as that's only self-deprecating), but "raping" is now "abusing".

Yeah, that's still loaded, but please keep in mind that the whole article is very much tongue-in-cheek. It's not about bro culture, or trying to make rape seem funny. I should have known better, but don't assume that "rape" must imply "violence towards women". I am guilty of using the former term, but certainly not in the meaning of the latter. All the compilers among you have my sincerest apologies.

Changed the host, should be fine now.

I admit that I went a bit overboard with the complaints about users, as seen in the out of context quote ;) This was mostly to accentuate that the few folks doing anything about D were (and still are) being ignored or actively bashed by the people in charge.

Sorry about that, looks like the VPS can't stand about any pressure :<

That latter advantage is true, but D's "header" files are currently impractical. Creating them by hand is a major source of pain, greater than with C/C++. The automatic generation on the other hand is troublesome for at least two reasons:

1) It's very sensitive to the contents of .d files. For instance, It leaves the bodies of inline-able functions in, thus if you modify such a function in the .d file, it will again mean a change spill to the .di and modules importing it (directly and indirectly). Similarly if you just reorder the functions in a module or change a private constant. This could partially be mitigated by a sufficiently smart build tool that tracks symbol importing, aliasing and usage in order to infer the modules that need to be recompiled. Sadly, this is quite complex and no current tool does it at the moment.

2) It assumes none of the functions will be used at compile-time (by stripping away function bodies depending on whether they may be inlined), which forces you to stuff them all into compile-time-only modules.

> - compilation is slow

What I've learned is that people don't really care about full builds when doing large projects. The separation into header and source files means that when you change a source file, only this one has to be recompiled. You only do massive rebuilds when modifying headers.

In case of D, when you modify a module, the change can possibly propagate indefinitely. Even when you just change the body of a function and think the modification should be isolated, consider that the build tool must assume this function may potentially be used at compile-time to generate code for other modules. The changes propagate as far as they would with .h files (unless the build tool can do semantic analysis or make unsafe assumptions).

To this fact, add how DMD only outputs template instances into one object file when compiling multiple modules at the same time. If you're lucky, at the next incremental build it will output them into the same modules. If you're not, you end up with unresolved references. This template emission method is an optimization - the alternative is a lot of bloat that object files generated by C++ compilers suffer from. I agree with Walter's position that what DMD does should be the default. And it is possible to make a good build tool that deals with this issue. I've tried doing that for DMD-Win, but its case, such a build tool is currently infeasible due to toolchain issues.

Wrong. D2 has features to ease multi-threaded development, so it's a language 'issue'.