Variable arguments with file and line information?

Jonathan M Davis jmdavisProg at gmx.com
Sun Nov 17 04:36:14 PST 2013


On Sunday, November 17, 2013 13:06:11 Chris Nicholson-Sauls wrote:
> Something I'm wondering: if one were to split the implementation
> along these lines:
> 
> 
> void error (string file = __FILE__, size_t line = __LINE__,
> Args...) (string msg, Args args) {
>      errorImpl(file, line, msg, args);
> }
> 
> void errorImpl (Args...) (string file, size_t line, string msg,
> Args args) {...}
> 
> 
> What are the chances of the middle-man function being inlined,
> thus cutting down on template bloat in the final product?  I
> should hope it would be practically guaranteed.

Without using -inline, the odds are zero. With the -inline... maybe. To be 
honest, dmd's inliner is horrible. e.g. it completely fails to inline any of 
std.ascii right now even though almost everything in there is a one line 
function. As I understand it, the fact that error and errorImpl are templates 
make it much more likely that they'll be inlined, but you'd have to compile 
them with -inline and look at the generated assembly code to find out for sure. 
We really, really need to improve the inliner.

But regardless, inlining has no effect on "template bloat." The fact that the 
function was inline does not get rid of the fact that it was instantiated, and 
it's possible that it would be inlined in some circumstances and not in 
others, making it so that the function definition would have to stick around. 
Also, I don't think that dmd does a very good job of stripping out template 
instantiations that aren't needed anymore (e.g. the ones used in template 
constraints like isForwardRange or isSomeString), so it _definitely_ isn't 
going to be smart enough to remove an instantiated template that's been 
inlined and then not used somewhere where it wasn't inlined.

- Jonathan M Davis


More information about the Digitalmars-d-learn mailing list