Re: Learning C

Richard G. Riley wrote:
On 2006-03-11, Nick Keighley <nick_keighley_nospam@xxxxxxxxxxx> wrote:
Richard G. Riley wrote:
"Nick"posted the following on 2006-03-11:
Richard G. Riley wrote:
"Chris"posted the following on 2006-03-10:
Richard G. Riley wrote:
"Nick"posted the following on 2006-03-10:

[ a long debate partly about using a debugger to analyse existing,
working
applications. Richard G. Riley thinks it's a good idea. I (Nick
Keighley) don't]

ok. This is *way* off topic. It has gone on too long. And the post has
grown
to gigantic proportions. I'm *really* going to stop now (I think I said
that
before...).

We are both probably frustratrated that the other doesn't seem to
understand our perefectly reasonable point of view. And everyone else
on
clc is probably even more frustrated that we both keep banging on.

What I do find odd is that we have drawn opposite conclusions for the
same
reason. Neither of us likes doing things manually that can be automated

(sign of a good programmer). So Richard objects to using printf() (or
custom
logger) because it is manual, error prone and may disturb the program,
and prefers using a debugger to achieve the same end. I object to the
use
of a debugger ***for exactly the same reasons*** !

<snip>

I find [a debugger] a good teaching tool to get people up
to speed with an app and its internal data structures : modify on the
fly, symbol tables etc. Cant do that with a print out or printfs.

I have *never* had any desire to do these things. Find the bug. Fix
the bug. Why would you want to modify things on-the-fly?!

Modify data to test or force a state. Its a basic of debugger use : you can
force your hand to avoid having to wait for a certain random data
suite to trigger the bug.

e.g someone says I'm getting a divide by zero somewhere near func().

go to func in debugger, force a zero into the divisor and see why the
checks arent stopping it. Simple example.

no. Put an assert() in. A modified variable is just for today. An
approriate
assert() lasts forever. Next year when someone casts doubt on the same
function, you simply look at the func() source code and say "nope,
can't
be a divide by zero because there's an assert() to check for that". Fix
it
once, never touch it again.

<snip>

I fail to see how analysing existing, successful apps can be anything
other than beneficial. It doesnt take away the donkey work of learning
the lanugage basics, but it can make text book "science" much more
accessible and "real". I cant imagine becoming a programmer without
such practice, guidance and "practical training". Its the same in all
walks of life.

I think I'll give up here. My point wasn't that important. Just trying
to make the point that different people do thinks in different ways. Linux
is not the only platform. Not everyone uses debuggers the way you do

Nobody said it was : you came flying in with that.

riight

You did. Look at the thread. The OP mentioned Linux : I said it was a
good idea for what he wanted to do : you came in with "hold on hold on
lets not start an OS war here".

a debugger war is much more fun...

<snip>

Maybe I'll even get my debugger out and step through a program
sometime to see if it brings me any insights. Maybe you should try
a "debugger free day" and try and see what you have to do to manage
without. Try reasoning about the program. Consider invariants and
post/pre conditions. Try adding asserts etc.

If you recall I did mention that a home brew logging system is
prefential to printf :

where did the words "homebrew logging system" appear in the paragraph
above? I did write a fairly blunt paragraph here. And then thought
better of it. Do you know what an invarient is? Design by contract?

I used those words. Its when you wrap whatever underlying logging system is
convenient to you in a fairly generic calling interface : so you could
log to files, text consoles, window systems whatever without changing
the calling code.

I note you didn't say if you knew what "Design by Contract" meant.

<snip>

A debugger isnt the only tool : and I never said it was. What it
can do is allow you to see the flow of an application while watching
live data, allow you to modify that data

never felt the need. Not since compilers got fast enough to run during
the day.

I really dont understand this. What has that got to do with a debugger?

I've modified variables using the debugger (the "debugger" actually had

toggle switches...) when the run time of the compiler was significant.
If it
took hours to recompile your code then machine code patches and
register
hacking was acceptable. It is no longer necessary (well, sometimes).

<snip>

and to examine and ensure
data typing is consistant from skillful use of register/pointer/memory
examinations : it is why they exist.

you examine registers? On a deeply embedded system, ok. But a
server?

I also mentioned memory and pointers. And yes I do. Very useful in
debugging big C systems.

wow. Culture Shockville. To my shame I couldn't even tell you what
registers
my platform has without STFWing. Ok that's a project for today.

<snip>

The whole crux here is you doubting
that stepping an existing app can help a user understand it : after
many, many and varied projects on various platforms in various
languages I find it incredulous how you could doubt this would be
beneficial. In order to even put in these printfs() you need some
understanding of whats going :

<snip>

I'd say the same went (in spades) for stepping. You've got to know
where
to step. There's source code, case tools, source browsers, source code.
I've even resorted to grep to find callers of functions.

grep is ok : if I dont have a decent IDE I use something like emacs
tags. I have used grep in about 15 years :)

ok it's a tool of desparation. You * never* use grep?!

<snip>


--
Nick Keighley

Testing can show the presense of bugs, but not their absence.
-- Dijkstra

.

Relevant Pages