#SC++ goofs
3 messages in this thread
Your proposal is contradictory with the notion of inline functions. An inline
function is closer to a macro than anything else; there is no code generated
for the function itself, but only where the function is referenced. Thus there
is no function to "step in to" with the debugger.
Symantec should be applauded for adding the 'use function calls for inlines'
debugging flag.
Rick Genter Useful Software Corporation
Rick,
I think you misunderstood what I was saying. In a section of source code like
this:
inline void AddOneTo (long &value) {value++;}
…
long a;
StringToNum ("\p123", &a);
AddOneTo (a);
…
you can set a breakpoint on the "NumToString" line (it has a diamond next to it
in the debugger), but you *can't* set a breakpoint on the "AddOneTo" line (no
diamond). This means that you can't stop and find out the value of 'a' just
before the "AddOneTo" call.
My point was that the original code is equivalent to:
StringToNum ("\p123", &a);
a++;
and so there is a piece of code ("a++") that *could* be marked with a debugging
line number, enabling breakpoints on the line.
I never asked for the ability to step *into* inline functions.
Regards,
Robin
BTW, it occurs to me that using "StringToNum" makes a good contrast. Since it's
a trap, it's implemented as an "inline" assembly macro and yet there's no
problem setting a breakpoint on that line. Wouldn't it upset you if you
couldn't set a breakpoint on any toolbox call?
You're right, I did misunderstand. I thought you were asking for the ability to
step into the inline function. Of course you should be able to stop on the call
to the inline function.
Rick Genter Useful Software Corporation