A Perspective on D from game industry

Manu via Digitalmars-d digitalmars-d at puremagic.com
Sun Jun 15 19:22:11 PDT 2014


On 16 June 2014 11:12, H. S. Teoh via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On Sun, Jun 15, 2014 at 12:51:12PM -0700, Walter Bright via Digitalmars-d wrote:
>> On 6/15/2014 6:50 AM, Peter Alexander wrote:
>> >The fear of meta programming comes from Boost, and rightly so in
>> >my opinion. Boost is written with the assumption that users will
>> >never have to read its source code. When it comes to debugging
>> >and performance tuning however, that assumption is shattered.
>>
>> For years I avoided C++ templates (even though I implemented them in
>> DMC++) because they were just so dang hard to read. D originally was
>> not going to have templates for that reason.
>>
>> But I eventually discovered that hiding behind the complexity of C++
>> templates was a very simple idea - templates are just functions with
>> compile time rather than run time arguments. (Isn't it amazing that I
>> could implement C++ without figuring this out? I still don't
>> understand that.) That was the enabling breakthrough for D templates.
>
> I think you may have missed the fact that your very realization was a
> further development in itself. The term "template" comes from the C++
> idea of having a pre-written piece of code with some blanks in a few
> places, that will be filled in to make the actual code. But the concept
> of "compile-time parameter" is something conceptually different, and
> more powerfully unifying IMO. It digs at the root of C++'s template
> nastiness, which ultimately comes from treating template parameters as
> something fundamentally distinct from function parameters. The ugly
> syntax is but the superficial expression of this underlying difference
> in conception. D's superior template syntax is not merely a better
> dressed syntax; it ultimately stems from treating template parameters as
> being the *same* thing as function parameters -- except they are
> evaluated at compile-time rather than runtime.
>
> This insight therefore causes D's templates to mesh very nicely with
> CTFE to form a beautifully-integrated whole.
>
>
>> In fact, templates engender such an "OMG! Templates! I don't get
>> Templates!" aura about them that I convinced Andrei to not even use
>> the word "template" in his book about D!
> [...]
>
> I like how TDPL introduces templates by not introducing them at all, but
> just talks about compile-time arguments. By the time the reader gets to
> the chapter on templates, he's already been using them comfortably.
>
> But on that note, perhaps it's not altogether a bad thing for the word
> "template" to have a negative connotation; perhaps we should be pushing
> the term "compile-time parameter" instead. It engenders an IMO superior
> way of thinking about these things that may help newcomers overcome the
> fear of metaprogramming.

Good points.

One thing I do think needs more emphasis though, is the true costs of
'compile time parameters'.
People tend to only consider runtime performance, and rarely consider
it in relation to binary bloat, or more subtle forms of performance
impact, like icache misses, which are more difficult to measure, and
rarely express themselves in benchmark environments.


More information about the Digitalmars-d mailing list