Walter Bright Wrote:
> It's not only asserts done in hardware, it's asserts with:
> 
> 1) zero code size cost
> 2) zero runtime cost
> 3) they're there for every pointer dereference
> 4) they work with the debugger to let you know exactly where the problem is
> 
> Seg faults are not an evil thing, they're there to help you. In fact, I'll often *deliberately* code them in so the debugger will pop up when it hits them.

</lurk>
While I get your point completely I believe this style of debugging is only really useful to the hard-core professional.

For the novice, where the debugger is a scary place of last resort, it would be more useful to have an assert too. All most of us want is a line number: and segfaults don't give us that.

If we also have an assert, hard-core programers can choose whether to assert or segfault, surely?. <lurk>

Walter Bright wrote:
> Georg Wrede wrote:
>> Walter Bright wrote:
>>> Kristian Kilpi wrote:
>>>> The problem is that assert(obj); does not first check if 'obj' is null.
>>>
>>> Yes it does, it's just that the hardware does the check, and gives you a  seg fault exception if it is null.
>>
>> Asserts were INVENTED to *avoid segfaults*.
> 
> The x86 had no hardware protection. When you wrote through a NULL pointer, you scrambled the operating systems, and all kinds of terrible, unpredictable things ensued. Asserts were used a lot to try and head off these problems.

Ok, sloppy wording on my part. "Pointer disasters" would've been more accurate.

> Seg faults are not an evil thing, they're there to help you. In fact, I'll often *deliberately* code them in so the debugger will pop up when it hits them.

That's okay. But what you do with D is hardly the average programming task. And not everybody uses a debugger. Many have their code run by others, and a phone call about a segfault is not an option. This is where asserts come in handy.

Sure, we can learn to write if(o) and assert(o !is null). Maybe this discussion should be deferred until nothing big is going on in D.

sambeau wrote:
> While I get your point completely I believe this style of debugging is only really useful to the hard-core professional.
> 
> For the novice, where the debugger is a scary place of last resort, it would be more useful to have an assert too. All most of us want is a line number: and segfaults don't give us that.

They do when combined with symbolic debug info - that is how the debugger is able to display your source code with the highlighted line where it seg faulted.


> 
> If we also have an assert, hard-core programers can choose whether to assert or segfault, surely?.
> <lurk>

But, anyways, an "Assert failed in line 178" is much more informative than "Program segfault".

You'll waste less time to fix the bug if you know which is the line that causes trouble, instead of doing these three steps: compiling with symbolic debug info, launching the program again and see where it crashes.

You could even fix the bug by just looking at line 178, without debugging.

Walter Bright escribió:
> sambeau wrote:
>> While I get your point completely I believe this style of debugging is only really useful to the hard-core professional.
>>
>> For the novice, where the debugger is a scary place of last resort, it would be more useful to have an assert too. All most of us want is a line number: and segfaults don't give us that.
> 
> They do when combined with symbolic debug info - that is how the debugger is able to display your source code with the highlighted line where it seg faulted.

Walter Bright wrote:
> sambeau wrote:
>> While I get your point completely I believe this style of debugging is only really useful to the hard-core professional.
>>
>> For the novice, where the debugger is a scary place of last resort, it would be more useful to have an assert too. All most of us want is a line number: and segfaults don't give us that.
> 
> They do when combined with symbolic debug info - that is how the debugger is able to display your source code with the highlighted line where it seg faulted.

Uh... I just don't feel like teaching all my potential testers what a debugger is, and that they should always run the game from within the debugger, or I won't be able to help when something goes wrong :/


-- 
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic on #D freenode

Walter Bright wrote:
> sambeau wrote:
>> While I get your point completely I believe this style of debugging is only really useful to the hard-core professional.
>>
>> For the novice, where the debugger is a scary place of last resort, it would be more useful to have an assert too. All most of us want is a line number: and segfaults don't give us that.
> 
> They do when combined with symbolic debug info - that is how the debugger is able to display your source code with the highlighted line where it seg faulted.
> 

Yes, but you still need the debugger to see it. The fact remains that many novices and stubborn professionals don't use debuggers, no matter how useful they are and how many times they are praised by others. They're happy with their printf debugging, even though they would probably be happier using a debugger, at least in some cases.

The situation is a lot like that of many C++ zealots who would like D a lot but simply refuse to try it for some reason or other. Invalidate that reason and you get more users.

In this case, either remove all asserts and force everyone to use a debugger in all cases, or add some asserts to make people generally happier and more productive when coding.

Personally, I find it annoying that most crashing bugs I can catch easily with a normal run of the program, but when it's "Access Violation" or "Win32 Exception" or "Segmentation fault", I have to recompile with -g and fire up the debugger to find out exactly what happened and where.

(OT: A similar case could be made for the Phobos call stack backtracing patch.)

-- 
Remove ".doesnotlike.spam" from the mail address.

Georg Wrede wrote:

> Sure, we can learn to write if(o) and assert(o !is null). 
> Maybe this
> discussion should be deferred until nothing big is going on in D.

Aww.  But we have to keep ourselves entertained *somehow* while Walter is off implementing const.  :-)

--bb

Georg Wrede wrote:
> Bill Baxter wrote:
>> Georg Wrede wrote:
>>> Walter Bright wrote:
>>>> Kristian Kilpi wrote:
>>>>> The problem is that
>>>>>
>>>>> assert(obj);
>>>>>
>>>>> does not first check if 'obj' is null.
>>>>
>>>> Yes it does, it's just that the hardware does the check, and
>>>> gives you a  seg fault exception if it is null.
>>>
>>> Asserts were INVENTED to *avoid segfaults*.
>>
>> What I find odd is that Walter often argues that things in D that
>> *look* like C++ should *act* like C++ as much as possible.
> 
> He should. This is a C family language, designed to woo the C(++) crowd
> out of their misery. So, things that "look" the same, should act
> unsurprisingly. And things that don't act like those folks expect,
> should look something diferent.

Right.  I was agreeing with you.  My point was that Walter *usually* advocates "things that look like C should act like C", but in this case he's going against his own advice.  I didn't mean to say that trying to make C constructs to do the same thing in D was odd.

--bb

Tom S wrote:
> Uh... I just don't feel like teaching all my potential testers what a debugger is, and that they should always run the game from within the debugger, or I won't be able to help when something goes wrong :/

you don't need to. just write a batch file that runs your program in the debugger and make it the default way to start the game for the testers. you'll have

Unhandled Exception: EXCEPTION_ACCESS_VIOLATION(0xc0000005) at _Dmain debugees\debuggee.d:237 (0x00402768)

instead of

Error: Access Violation

The problem with access violations is that the CPU raises them, the OS handles them and throws the exception. In order to have the same info in those exceptions as we have in D exceptions, they need to be intercepted and decorated with filenames and source line numbers - data that is available at runtime only from debug symbols. That means, that there needs to be a runtime that can interpret debug symbols and that basically is shipping half a debugger with the executable.

Ary Manzana wrote:
> You'll waste less time to fix the bug if you know which is the line that causes trouble, instead of doing these three steps: compiling with symbolic debug info, launching the program again and see where it crashes.
> 
> You could even fix the bug by just looking at line 178, without debugging.

there is no way how access violations can have line numbers without adding debug symbols (read: line numbers) to the executable.
imho, using -g should be default during development and testing.