Trouble creating a formatted assert wrapper

[Don Clugston]

On 04/09/12 11:43, Chris Nicholson-Sauls wrote:
> On Tuesday, 4 September 2012 at 09:24:26 UTC, Don Clugston wrote:
>> On 03/09/12 23:48, Chris Nicholson-Sauls wrote:
>>> I reiterate my impression that magical __FILE__ and
>>> __LINE__ should be provided by some other means.
>>
>> It was a special-case hack to fix a special-case need. It was
>> extremely easy to implement (about 2 hours work) and has been very
>> successful in fixing that need. Everything else that anyone has talked
>> about is at least ten times as complicated, and doesn't seem to offer
>> significant advantages.
>>
>> It's really easy to come up with over-engineered solutions to these
>> sorts of things.
>
> How difficult would hidden params, triggered by usage, be?  Ie: my
> function makes use of __CALL_FILE and __CALL_LINE variables by name,
> therefore they are tacked on  (as const, presumably) and always passed,
> thanks to diabolic compiler sorcery.  The current solution is fine in a
> majority of cases, at least so far, but there are going to be moments
> like what the OP had, and these moments are discouraging especially to
> newcomers.

I don't know how that could be done. You need to know the function 
signature whenever you call the function. If you make the signature 
dependent on the function body, it cannot work unless you have the 
source code of the function. The compiler is able to add hidden 
variables for things like 'this' because it can work out if it is 
required just by looking at the types involved in the function 
declaration. But in this case, it can't get it from the signature.

The default argument method we are currently using is a nice trick, 
because even though default arguments aren't part of the function type, 
the compiler still sees them in the function signature, so it knows to 
do a bit of magic.

It's also easy to get nasty forward reference errors when you do that 
sort of thing.


>
> I won't pretend to know if it would be easy or not; you're a heck of a
> lot more familiar with the compiler's code than I am.  But it certainly
> seems straightforward.