modulename

[Jonathan M Davis]

On Wednesday, September 05, 2012 20:46:08 Andrej Mitrovic wrote:
> On 9/5/12, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> > Regardless of whether it works, __FILE__ and __LINE__ should be used as
> > template arguments with extreme caution, because you end up with a new
> > instantiation for _every_ use (at least if you use both together).
> 
> Honestly it would be much better if the file and line were symbols you
> could retrieve at any point in your function, e.g.:
> 
> void foo()
> {
> string file = __FILE__; // file of inside
> int line = __LINE__; // line inside foo
> 
> string callFile = __INFILE__; // file of invocation
> int line = __INLINE__; // line of invocation
> }
> 
> That way you don't have to mess with your CT/RT parameters if all you
> want to do is printf-style debugging.

That would be _way_ harder to implement. As it is, it's trivial to insert the 
__FILE__ and __LINE__ as default arguments at the call site. Doing __INFILE__ 
or __INLINE__ would require providing additional, invisible arguments to the 
function for the __FILE__ and __LINE__ at the call site, and it would 
invisibly change the function's signature depending on whether __INFILE__ 
and/or __INLINE__ were used in the function or not. I'd be very surprised if 
that sort of thing were considered acceptable by the compiler devs.

With how C linkage is designed, it doesn't care about the call site at all. A 
function has no idea where it's called from and doesn't care. The only reason 
that we got __FILE__ and __LINE__ to work like they do with default arguments 
is because it was trivial to change it so that they used the values at the 
call site rather than the declaration site, because those values are copy-
pasted at the call site anyway. Anything which would require the function 
itself actually having access to the scope that it was called from would 
complicate things considerably.

- Jonathan M Davis