Sean Kelly wrote:
> Walter Bright wrote:
>> Sean Kelly wrote:
>>> Walter Bright wrote:
>>>> It does check if it's null. That's how the access violation exception gets thrown.
>>>
>>> But that's generated by the hardware, isn't it?
>>
>> Yes.
>>
>>> Shouldn't assert explicitly check whether c is null before calling its invariant?
>>
>> Why, if the hardware does it for you (without extra bloat)?
> 
> Just so a file and line number are available.  Though someone mentioned the code already does something like "assert(obj); obj.invariant();" and the problem here was that it was a release build?  If this is the case I'm fine with the current behavior.  I really only care about this sort of thing if asserts are enabled.

Yes, an assert(o !is null) is performed. But it's performed *inside* _d_invariant, which is part of Phobos. And since Phobos is only distributed as a release build, that means the assert is off by default _even if *your* program has asserts enabled_. You need to recompile Phobos to change this behavior. This is bad.

Perhaps that assert should just be converted to an "if (!o) _d_assert(__FILE__, __LINE__)" since _d_invariant will (presumably) only be called if the application has assertions enabled?

Frits van Bommel wrote:
> Sean Kelly wrote:
>> Walter Bright wrote:
>>> Sean Kelly wrote:
>>>> Walter Bright wrote:
>>>>> It does check if it's null. That's how the access violation exception gets thrown.
>>>>
>>>> But that's generated by the hardware, isn't it?
>>>
>>> Yes.
>>>
>>>> Shouldn't assert explicitly check whether c is null before calling its invariant?
>>>
>>> Why, if the hardware does it for you (without extra bloat)?
>>
>> Just so a file and line number are available.  Though someone mentioned the code already does something like "assert(obj); obj.invariant();" and the problem here was that it was a release build?  If this is the case I'm fine with the current behavior.  I really only care about this sort of thing if asserts are enabled.
> 
> Yes, an assert(o !is null) is performed. But it's performed *inside* _d_invariant, which is part of Phobos. And since Phobos is only distributed as a release build, that means the assert is off by default _even if *your* program has asserts enabled_. You need to recompile Phobos to change this behavior. This is bad.
> 
> Perhaps that assert should just be converted to an "if (!o) _d_assert(__FILE__, __LINE__)" since _d_invariant will (presumably) only be called if the application has assertions enabled?

I think the problem is more that Phobos only ships with a release build rather than that the code is broken.  What should probably be the case is that DMD should link phobos.lib if -release is set and link phobosd.lib otherwise.  Specifying both -debug and -release... well, I'm not sure what that does so I can't say :-)


Sean

Sean Kelly wrote:
> Frits van Bommel wrote:
>> Yes, an assert(o !is null) is performed. But it's performed *inside* _d_invariant, which is part of Phobos. And since Phobos is only distributed as a release build, that means the assert is off by default _even if *your* program has asserts enabled_. You need to recompile Phobos to change this behavior. This is bad.
>>
>> Perhaps that assert should just be converted to an "if (!o) _d_assert(__FILE__, __LINE__)" since _d_invariant will (presumably) only be called if the application has assertions enabled?
> 
> I think the problem is more that Phobos only ships with a release build rather than that the code is broken.  What should probably be the case is that DMD should link phobos.lib if -release is set and link phobosd.lib otherwise.  Specifying both -debug and -release... well, I'm not sure what that does so I can't say :-)

Separate libraries is also an option, of course ;).