Possible solution to template bloat problem?
Dicebot
public at dicebot.lv
Mon Aug 19 17:48:27 PDT 2013
On Tuesday, 20 August 2013 at 00:34:38 UTC, Ramon wrote:
> Well, I'm afraid that's what templates are. One (or the
> compiler) fills them in and that's it.
>
> In other words: Templates are compile time while (real)
> generics are run time. This basically comes down to have some
> way of designating classes as, for instance, comparable and
> then either running along the object chain comparing all built
> in objects (with built in compare functionality) or having a
> compare implemented (Of course, there is also arithmetic
> functions, etc.).
>
> While this sounds great it actually carries some code weight
> ("bloat") with it, too because all that functionality must be
> somewhere. It gets (relatively) cheaper though when being
> heavily used.
What you speak is true for languages with "generics" where amount
of generated code is pretty much equal to one that would have
been written by hand. But in D templates do much more and there
is no practical reasons other one quality of implementation to
keep it that way.
For example, template constraints and stuff used during CTFE are
low-hanging fruits. Those don't need to be emitted in resulting
executable at all being only used at compile time.
More theoretically complex problem is stuff like std.algorithm -
simply using something like map will result in several hundreds
(!) of trivial template instances most of which will be inlined
and never actually used in resulting binary. That is something
that link-stage gargabe collection can take care of with a
totally awesome results. I doubt it can be done by compiler
itself but maybe there are some options I have missed.
In a perfect world using templates implies generic algorithms not
generic code generation. it same thing as manual assembly - with
modern optimizers and inlining capabilities all this crap must be
boiled down to same code as carefully crafted manual one. No
reasons to not do it.
Reminds me: how hard is writing own linker is again? :)
More information about the Digitalmars-d
mailing list