A modest proposal: eliminate template code bloat

[H. S. Teoh]

On Sun, Apr 08, 2012 at 08:45:19PM +0400, Dmitry Olshansky wrote:
> On 08.04.2012 18:18, H. S. Teoh wrote:
> [snip]
> >We'd have to make sure the checksum doesn't end up in the final
> >executable though, otherwise the bloat may negate any gains we've
> >made.
> 
> Easy the symbol size is in object file (obviously) but it surely not
> present in the executable. If I worth anything legacy formats have a
> plenty of slack space reserved for future. Nwo is the future :)

I agree!


[...]
> >>Applicability:
> >>It's not only const-immutable bloat, it can be alleviated with
> >>inout. Yet there are plenty of places the exact same code is being
> >>generated: e.g. sealed containers of int vs uint, std.find on
> >>dchar[] vs uint[]/int[] an so on.
> >>In general, the coarse grained parametrization is the root of all
> >>evil and it is inevitable since we are just humans after all.
> >
> >I'm not sure I understand the last sentence there, but duplicate code
> >elimination is definitely a big plus. It will also mean that we can
> >use templates more freely without having to worry about template
> >bloat.
> 
> It's easy - define a template on type T. Code it up.
> Now how many times you did consider that e.g. you can parametrize on
> the size of the type instead of the type itself? I'm making a point
> that it's almost always the case with sealed containers of PODs for
> instance.
> (now multiply the argument for total number of parameters)

Yeah, that's what I was thinking of. This would be a very big gain for
the new AA implementation, for example. I wouldn't have to worry so much
about template bloat if most of the instantiations are going to get
merged anyway. :-)


[...]
> >Not really... string pooling can take advantage of overlapping
> >(sub)strings, but I don't think you can do that with code. But I
> >think your idea has a lot of merit. I'm for making linkers smarter
> >than they currently are.
> >
> 
> Sorry, it's just me running ahead of train somewhat. Basically once
> this initial version is in place I have one cool refinement for it in
> mind. For now we just need to keep the hash function transitive and
> associative for the gods sake. 128/64bit checksum please ;)
[...]

And what would the cool refinement be? :-)


T

-- 
It's bad luck to be superstitious. -- YHL