On Wednesday, September 05, 2012 20:46:08 Andrej Mitrovic wrote:
> On 9/5/12, Jonathan M Davis <jmdavisp...@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
