On Wed, 31 Aug 2011 01:35:51 -0400, Walter Bright
<newshou...@digitalmars.com> wrote:
On 8/30/2011 6:28 PM, Brad Roberts wrote:
On Tue, 30 Aug 2011, Walter Bright wrote:
On 8/30/2011 5:08 PM, Bernard Helyer wrote:
On Tue, 30 Aug 2011 16:19:00 -0700, Walter Bright wrote:
Looking for corruption of the data.
Why doesn't it check for null, and pass if no invariant is defined?
Because the hardware does the null check for you, which is what a seg
fault
is.
The frequency with which this comes up and the lack of converts to that
point of view ought to tell you something here. :)
I am simply baffled by it.
Seg faults are not as useful as asserts. It's a fact. If you have a seg
fault, you must reproduce the error while in a debugger, or generate a
core dump. Reproducing not be possible, or might take considerable time.
Any argument against this is revisionist history. Yes, if I go back in
time and run it in a debugger for that execution, it would be useful.
Yes, if I go back in time and change my shell options to generate a core
dump, it would be useful. If you have an assert, you get a stack trace,
no need to reproduce the assert in a debugger, or enable non-default
settings in your shell. It just gives you the information you need.
Would you entertain a pull request with this fairly simple change?
It'll add a lot of bloat.
Define "a lot"...
Running a test:
class C {}
void foo(C c)
{
int x = 1;
version(bloat)
{
if(c !is null)
assert(c);
}
else
{
assert(c);
}
}
diff bloat.asm nobloat.asm
< mov -4[EBP],EAX
< cmp dword ptr -4[EBP],0
< je L17
< mov EAX,-4[EBP]
So 4 instructions per assert of a class reference (which is arguably not
common) is a lot of bloat? And let's not forget that we are not in
release mode here, the bloat does not affect release code. In other
words, people are willing to have 4 extra instructions per function in
order to avoid needless seg faults.
You can actually *DO AWAY* with all this bloat by instead calling a global
runtime assertObject function, which first checks that the object is not
null, then calls object.__invariant.
This is a similar approach that opEquals has.
-Steve