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
