![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 10/25/2010 3:52 PM, Orchid XP v8 wrote:
> It's pretty self-evident that if you put a breakpoint on the name of a
> function, you want it to break every time that function is called.
>
> (It's also pretty self-evident that having some visual feedback about
> where you can and can't put breakpoints would help enourmously.)
>
Remember: The function declaration is just that: A declaration. It has
no code. Depending on the compiler and execution environment the actual
code will be the first statement with the potential addition of
declarations of variables with assignment.
On the second point. Yeah, I agree it would be nice.
--
~Mike
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Mon, 25 Oct 2010 21:52:54 +0100, Orchid XP v8 wrote:
> It's pretty self-evident that if you put a breakpoint on the name of a
> function, you want it to break every time that function is called.
Perhaps, but it's also self-evident that the function *name* isn't
executed, so it makes no sense to set a breakpoint on a line that
contains non-executable code, since a breakpoint interrupts the flow of
*executable* code. ;-)
> (It's also pretty self-evident that having some visual feedback about
> where you can and can't put breakpoints would help enourmously.)
Now *that* I can't argue with. ;-)
Jim
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 26/10/2010 04:27 PM, Jim Henderson wrote:
> On Mon, 25 Oct 2010 21:52:54 +0100, Orchid XP v8 wrote:
>
>> It's pretty self-evident that if you put a breakpoint on the name of a
>> function, you want it to break every time that function is called.
>
> Perhaps, but it's also self-evident that the function *name* isn't
> executed
Oh really?
> so it makes no sense to set a breakpoint on a line that
> contains non-executable code, since a breakpoint interrupts the flow of
> *executable* code. ;-)
Until now, I haven't seen a debugger that prohibits you putting
breakpoints on (say) a completely empty line. I mean, hell, isn't the
debugger's job supposed to be to make your job *easier*? :-P
> Now *that* I can't argue with. ;-)
Heh. All it needs now is for some helpful soul to suggest that I submit
a source code patch. :-P
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Tue, 26 Oct 2010 16:38:18 +0100, Invisible wrote:
> On 26/10/2010 04:27 PM, Jim Henderson wrote:
>> On Mon, 25 Oct 2010 21:52:54 +0100, Orchid XP v8 wrote:
>>
>>> It's pretty self-evident that if you put a breakpoint on the name of a
>>> function, you want it to break every time that function is called.
>>
>> Perhaps, but it's also self-evident that the function *name* isn't
>> executed
>
> Oh really?
Yes, really. A function name is non-executable code - it's a reference.
>> so it makes no sense to set a breakpoint on a line that contains
>> non-executable code, since a breakpoint interrupts the flow of
>> *executable* code. ;-)
>
> Until now, I haven't seen a debugger that prohibits you putting
> breakpoints on (say) a completely empty line. I mean, hell, isn't the
> debugger's job supposed to be to make your job *easier*? :-P
You've never used Borland's C compiler then. Or MASM, or TASM. ;-)
How exactly does it make the job easier if the debugger lets you set
breakpoints in places that logically make absolutely no sense?
>> Now *that* I can't argue with. ;-)
>
> Heh. All it needs now is for some helpful soul to suggest that I submit
> a source code patch. :-P
Well, submit a patch. ;-)
You're welcome.
Jim
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> Yes, really. A function name is non-executable code - it's a reference.
>
> How exactly does it make the job easier if the debugger lets you set
> breakpoints in places that logically make absolutely no sense?
I'd argue that setting a breakpoint on a function name means the code breaks
every time that function is called. That seems pretty logical to me.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Mike Raiford wrote:
> Remember: The function declaration is just that: A declaration. It has
> no code.
That's your inner nerd speaking.
The actual answer is "if he tries to put a breakpoint on the function name,
he wants to breakpoint when the function is called, so we'll actually put
the breakpoint on the first executable statement of the function."
This is exactly the way in which open source software tends to suck: written
by geeks, for geeks, which is great unless you're not a geek. :-)
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Tue, 26 Oct 2010 17:05:31 +0100, scott wrote:
>> Yes, really. A function name is non-executable code - it's a
>> reference.
>>
>> How exactly does it make the job easier if the debugger lets you set
>> breakpoints in places that logically make absolutely no sense?
>
> I'd argue that setting a breakpoint on a function name means the code
> breaks every time that function is called. That seems pretty logical to
> me.
If I want to do that, I'll set it up on the first line of executable code
in the function. That makes logical sense to me.
If I go into, say, the NetWare kernel debugger (which I have spent many,
many months in), I can set a breakpoint at a "function", but the function
is a reference to the first executable line of machine code inside the
function IIRC (Now I think of it, it might be on the call itself - I may
need to restart my VM and look again at that).
Jim
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 10/26/2010 12:33 PM, Darren New wrote:
> Mike Raiford wrote:
>> Remember: The function declaration is just that: A declaration. It has
>> no code.
>
> That's your inner nerd speaking.
>
I don't think it's inner :)
>
> This is exactly the way in which open source software tends to suck:
> written by geeks, for geeks, which is great unless you're not a geek. :-)
>
YES! Exactly. Though I do like some OSS projects. But this is a major
issue with OSS is it tends to be developed with exactly that mindset.
--
~Mike
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> This is exactly the way in which open source software tends to suck:
>> written by geeks, for geeks, which is great unless you're not a geek. :-)
>
> YES! Exactly. Though I do like some OSS projects. But this is a major
> issue with OSS is it tends to be developed with exactly that mindset.
"Patches welcome."
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible wrote:
>>> This is exactly the way in which open source software tends to suck:
>>> written by geeks, for geeks, which is great unless you're not a geek.
>>> :-)
>>
>> YES! Exactly. Though I do like some OSS projects. But this is a major
>> issue with OSS is it tends to be developed with exactly that mindset.
>
> "Patches welcome."
Oh, yes, that works great.
Problem: Only programmers are comfortable with the program.
Solution: Submit code.
Yeah. Think about that one.
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |