NotNull pointers
Timon Gehr
timon.gehr at gmx.ch
Tue Aug 30 16:52:49 PDT 2011
On 08/31/2011 01:19 AM, Walter Bright wrote:
> On 8/30/2011 4:07 PM, Timon Gehr wrote:
>> You mean, in release mode the assert gets compiled out, and it seg
>> faults in the
>> code sequence that depends on the assertion, right?
>
> Yes. Any dereference of a null class ref would cause a seg fault.
>
>> I am not afraid of seg faults so much, but in debug mode it is
>> certainly an
>> annoyance, because you don't get the source line and stack trace. I'd
>> say it
>> would be really nice if assert(classreference); would never seg fault
>> during
>> debugging.
>
> Why? I rely on that for debugging. I run it under the debugger, seg
> fault, bing the debugger shows where it faulted and a stack trace. It's
> about 98% of what a debugger is good for.
I don't usually run my programs in a debugger, and with a few assertions
now and then this is practical. For me, a seg fault is always more of a
productivity blocker than an AssertError.
>
> Andrei will reply that there are some environments where you cannot use
> a debugger, and he's right. But there are other workarounds for that - D
> doesn't *prevent* you from doing soft debugging.
It does prevent me from writing assert(classreference); for no apparent
reason. :)
>
>
>> Is there any practical use for manually running the class invariant?
>
> Looking for corruption of the data.
>
Well, ok.
But is there any reason why assert(classreference); should not be
changed to assert(classreference !is null &&
classreference.__invariant()); ?
Basically, all it does is making debugging more pleasant if you don't
run a debugger, and save you some key strokes.
(It is also more consistent, because assert(classreference&&1); will
never segfault either.)
More information about the Digitalmars-d
mailing list