Sorry, other way around. It does force the stringification at compile time.
It makes sense that would be more efficient, except that we're doing
something much more complicated these days:
macro assert(ex,msgs...)
msg = isempty(msgs) ? ex : msgs[1]
if !isempty(msgs) && isa(msg, Expr)
# message is an expression needing evaluating
msg = :(string("assertion failed: ", $(esc(msg))))
elseif isdefined(Base,:string)
msg = string("assertion failed: ", msg)
else
# string() might not be defined during bootstrap
msg = :(string("assertion failed: ", $(Expr(:quote,msg))))
end
:($(esc(ex)) ? $(nothing) : error($msg))
end
On Wed, Feb 19, 2014 at 11:49 AM, andrew cooke <[email protected]> wrote:
> ah, cool, thanks. ok, so i wasn't *that* confused. makes mores sense
> after readig more of the chapter (sorry). andrew
>
>
> On Wednesday, 19 February 2014 13:43:06 UTC-3, Stefan Karpinski wrote:
>
>> I believe that Jeff changed that to make the code generated by assertions
>> less costly to evaluate in the common case that the assertion isn't
>> triggered. I'm not certain why delaying the string construction to run time
>> does that, but it seems to.
>>
>>
>> On Wed, Feb 19, 2014 at 11:41 AM, andrew cooke <[email protected]> wrote:
>>
>>> according to http://julia.readthedocs.org/en/latest/manual/
>>> metaprogramming/ @assert is defined as:
>>>
>>> macro assert(ex)
>>> :($ex ? nothing : error("Assertion failed: ", $(string(ex))))end
>>>
>>> and i am wondering why there is a $(...) around the call to string. is
>>> this to delay evaluation?
>>> if so, why?
>>>
>>> thanks,
>>> andrew
>>>
>>>
>>>
>>>
>>
