B
Ben Pfaff
dave said:
For what it's worth, I wasn't trying to imply that one choice was
necessarily better than the other.
For what it's worth, I wasn't trying to imply that one choice was
necessarily better than the other.
P
pete
Richard said:
It was a contrived example for my "exactly perfect" claim.
I was responding to this false claim by Richard Harter:
"> Indeed. A disadvantage, though, is that n does not correspond to
"> array indices. An alternate formulation is
> for (; --n >= 0{}
> This can be useful if one wants to work, so to speak, from the high
> end to the low end of an array.
.... which he wrote in response to my saying:
"To me,
while (n-- != 0) {}
is very easy to read as a loop that's going to iterate
as many times as what the initial value of n is.
"
That's the way that I actually have mem_cpy written
in my toy library.
Mostly, I prefer to increment pointers
rather than to increment offsets.
C
Chris Torek
while(n--)
[as compared to a loop using p1[n] and p2[n], instead of postfix-++]
Indeed, most optimizing compilers will do so. If the number of
trips through the loop is predictable (or easily computed), most
optimizing compilers will unroll to a greater extent; and if the
semantics are similar enough (e.g., if both loops in the original
samples had done a forward copy, which was not the case here), a
good compiler will often produce the same machine code for either
one.
The resulting machine code is not all that illustrative, however.
The point of the example in this case was to show that, in some
cases, indexing is actually *faster* than pointer arithmetic, as
there is only one variable to update (in this case, n) instead of
several (in the other case, n, p1, and p2). A great deal depends
on both the target machine architecture and the compiler.
The moral, as it were, is to avoid "knowing too much that is not
actually true" about the target machine code, and thus doing
low-level source code "optimization" that is actually more of a
pessimization. Instead, write the code as clearly as you can
manage. Then, after it works, use a tool like a runtime profiler
to find out where it really spends critical amounts of time -- and
optimize there, preferably algorithmically (but if it is really
important, go ahead and twist up the source in micro-optimizations
if needed).
[as compared to a loop using p1[n] and p2[n], instead of postfix-++]
Indeed, most optimizing compilers will do so. If the number of
trips through the loop is predictable (or easily computed), most
optimizing compilers will unroll to a greater extent; and if the
semantics are similar enough (e.g., if both loops in the original
samples had done a forward copy, which was not the case here), a
good compiler will often produce the same machine code for either
one.
The resulting machine code is not all that illustrative, however.
The point of the example in this case was to show that, in some
cases, indexing is actually *faster* than pointer arithmetic, as
there is only one variable to update (in this case, n) instead of
several (in the other case, n, p1, and p2). A great deal depends
on both the target machine architecture and the compiler.
The moral, as it were, is to avoid "knowing too much that is not
actually true" about the target machine code, and thus doing
low-level source code "optimization" that is actually more of a
pessimization.
Instead, write the code as clearly as you canmanage. Then, after it works, use a tool like a runtime profiler
to find out where it really spends critical amounts of time -- and
optimize there, preferably algorithmically (but if it is really
important, go ahead and twist up the source in micro-optimizations
if needed).
R
Richard G. Riley
You are joking?
For sure.
R
Richard G. Riley
Its interesting : I will have a look at some asm for intel compilers.
I must admit to hating array notation.
C
Chris Dollin
Richard said:
Why should he be joking?
The last C project I did - a compiler/shortcode interpreter for
a scripting language - I hardly used a debugger at all, and when I
did, it was to get a stack-trace and line-number because that
doesn't happen for free when the code went whoopsie.
[Similarly, writing Java code in Eclipse it was /months/ before I
found out how to use the debugger -- a colleague used it in front
of me -- and I still regularly don't use it. I do rely on being
able to get a backtrace, though, but you don't have to use the
debugger to get /those/.]
R
Richard G. Riley
His comment was "cannot remember the last time" : clearly a very
personal thing. Not somethign to recommend or aim for IMO.
Littering code with printfs or the quivalent plain sucks unless its
for logging purposes and is well DEFd out : even then it can
unecessrily break p the flow and readability of the code.
Its why debuggers exist. Only the most trivial
or tiny code can be maintained or properly examined with messy and
time consuimg printfs. printfs only show what you *think* you need to
know : not the true state of memory, locals, stacks, memory blocks.
In addition printfs dont give you watchpoints, breakpoints etc. I cant
even believe we are having this discussion to be honest, although I
suppose you're not necessarily defending it : just that it can be done
- on that we are agreed.
If you can get away with it fine. Its certainly not something that
would generally be encouraged in any programing environment I have
been involved in.
It must be a personal thing. For me the debugger is as crucual a part
as the editor : I would normally always step through the
debugger just to sniff out any issues with uninitialised stuff,
pointer run throughs etc. Its why IDEs put so much effort into the
debugger part these days.
V
Vladimir S. Oka
Richard said:
You seem to completely ignore the world of deeply embedded devices.
With those, logging is sometimes the only (convenient) way of getting
debugging output. The debuggers are not part of your IDE, but
standalone applications requiring extra cables, and hardware add-ons.
Now imagine, using them in the back seat of a taxi while field testing
the latest mobile gadget. Much more convenient if you only have yur
gadget, a laptop, and a serial cable (they're also usually sufficient
for a quick recompile with different debug outputs). See the point?
said:
There are also, AFAIK, two major schools of thought. You obviously
belong to one that believes debuggers are panacea. The other one (and I
count myself in there) believes that if you have to use the debugger
you have failed to understand the problem/code at hand (but it does
have it's use in extreme cases). Obviously, these are the extremes, and
all shades in between exist as well.
N
Nick Keighley
Richard said:
A_buffer[6] = (unsigned char) ((buffer[3] & 0xfc) |
((buffer[4] >> 6) & 0x03));
*(A_buffer + 7) = (*(buffer + 4) & 0x1f) |
((*(buffer + 4) << 2) & 0x80) |
((*(buffer + 3) << 5) & 0x60);
memcpy(A_buffer + 8, buffer + 5, 5);
R
Richard G. Riley
I did not ignore that at all. I simply didnt address it : although I
did mention "for logging" purposes. In fact I even put "for logging
purposes".
In addition, as you know, there are frequently emulators for such
devices. But that is moving OT a little.
I dont disagree.
The limitations of such devices and infrastructure should in no way
blinker one to the benefits of a code/debug technique when such
facilities do exist.
If you have to use a debugger you have failed to understnd the
problem/code????
I am astonished. In many years of programming in multiple languages on
multiple platforms I have never heard this school of thought.
A debugger isnt just there to find bugs : it is there to control the
flow of the program to ensure no bugs. Runtime modifications of
variables for loop conditions, stack removals, the list goes on.
Any professional programmer who doesnt make use of such facilities is
a very special person.
R
Richard G. Riley
Richard said:
A_buffer[6] = (unsigned char) ((buffer[3] & 0xfc) |
((buffer[4] >> 6) & 0x03));
*(A_buffer + 7) = (*(buffer + 4) & 0x1f) |
((*(buffer + 4) << 2) & 0x80) |
((*(buffer + 3) << 5) & 0x60);
memcpy(A_buffer + 8, buffer + 5, 5);
lovely
C
Chris Dollin
Richard said:
/I/ think it's something to aim for.
I don't know what CB does: I do know that I don't leave debugging
printf in code. I will leave logging statements in code, but I use
precious few of those either. (The distinction is just that the
logging stuff is for some switchable record of things that happen,
which need not be for debugging but for explanation or exposure.)
Well ... will you count specialised output functions as logical
printfs? Because those were my tools of choice when I needed to see
internal state of code under development. Perhaps my code was tiny,
or trivial, by your standards - but I would have described using a
debugger on it as an act of madness.
I've never found that to be a problem.
Oh, I /am/ defending it. In my (limited) C experience, I have not
needed to resort frequently to a C debugger. I would expect to need
one less nowadays than I used to, as well.
Developing code in a way that doesn't require using a debugger wouldn't
be encouraged? Really?
I suspect we have some fundamental disconnect somewhere. Debuggers are
tools of last resort, in my view. Perhaps we mean different things by
"debugger".
I'd like there to /be/ a debugger, and for it to be decent, because
being a tool of last resort doesn't mean that it shouldn't /work/;
sometimes you end up against the wall. It's just that in the normal
course of developing my C software, I didn't have reason to use one.
Maybe there's an application area difference.
R
Richard G. Riley
As I mentioned before a debugger is not just for finding bugs when
they are there. It is used as a vital TESTING tool.
We will agree to disagree : for me, when available, a debugger is an
indispensable aid to good productivity and ultimately bug free
code. It also enourages a coding style which facilitates debugger use
and, as a result, better maintainability by future generations. And
this I have some experience of.
To aim "not to use a debugger" is, for me, preposterous.
V
Vladimir S. Oka
Richard said:
There are much better testing tools than a debugger.
Debuggers are not there to /find/ bugs. They are there to help you
/fix/ them once found (and that, more often than not, happens /outside/
the debugger).
C
Chris Dollin
Richard said:
Ye gods and little fishes, a debugger is no more a testing tool than
a rainbow is a three-volume novel. You /must/ mean something different
by debugger than I do.
Colour me gobsmacked.
C
Chris Hills
Chris Dollin said:
You are wrong. There are several unit and system test systems that work
with an ICE or JTAG to test the system and software on the target
hardware.
On one project I did the all the unit test for a system using an ICE to
run the code on the hardware. the white box system test was also done
using an ICE on some parts only a BDM or JTAG is available not an ICE.
This sort of testing is virtually mandated on safety critical systems
after all how do you do MDSC code coverage without an ICE or debugger?
You are.
However you would not
C
Chris Dollin
Chris said:
I think this may be the "something different". When I say "use the
debugger" I mean a human working interactively with a tool to locate
a point of failure in a system, by placing break/watch-points on
locations/triggers and looking with the eyes at the machine state.
What you describe sounds perfectly sensible - but I wouldn't describe
it as "using a debugger"; I think this is the disconnect.
[I don't know if I'd call the tools you mention "debuggers", either, but
it's too late to know for sure whether I wouldn't have /before/ this
discussion.]
V
Vladimir S. Oka
Chris said:
I think "ICE" is a giveaway. It stands for In Circuit Emulator (I know
you all know). The fact that some good tools (cf. Lauterbach) often
bundle them with their debuggers can lead to confusion. And yes, in
this combination they can be powerful, even irreplaceeable, testing
tools.
However, I'm afraid that's not what Richard meant earlier.
R
Richard G. Riley
You have just lost all possible reason for being listened to. That is total
and utter rubbish. You are clearly not familiar with debuggers.
While many bugs can and are found outside of debuggers, many can only
be caught with HW breakpoints and clever watch expressions. This in
addition to using a debugger as a<testing tool by tweaking run time
valuesto test the robustness of certain routines.
R
Richard G. Riley
You are discussing rationally so lets stick with this. Everything you
have just said is exactly what I mean by using a debugger. A debugger
isnt only there to locate a point of failure although clearly that is
a major use. It can also be used, as I have repeatedly stated, to test
the system at run time. You can even connect to running processes in
most systems.
I *always* use a debugger to run through any meaningful critical
code. It enables me to cast an eye over memory, stacks, locals etc. It
is an added safety barrier beyond my own smug ability to write error
free code
Debugger. Eclipse "debugger". gdb. All debuggers. All code development
tools. All very much used in any real SW development cycle.