Re: signal

Arthur J. O'Dwyer" writes:
As you wisely remarked, user923005 did have some excellent advice in
there among the "misanthropy". ;) Get K&R; it's a great resource. As for
the difference between int foo() and int (*foo)(), you might find the
following lecture notes useful. Or not. I'm not sure.
http://www.contrib.andrew.cmu.edu/~ajo/free-software/getline/parsing.html

First, I would like to emphasize that I never claimed to be a competent
programmer. I never took a programming course in school and am essentially
self taught. In the last couple of years I have made a lot of progress in
programming, in the sense that I am increasingly able to write programs that
compile and run according to my expectations, and to figure out what is wrong
with them when they don't. Even so, I don't have systematic and comprehensive
knowledge of the computer systems and languages I use. I realize that this
imposes certain limitations on what I can accomplish but that is the way it
has to be, given my other priorities. Meanwhile, I try to learn things as
I perceive the need to do so and I don't normally have time to do it in the
manner and order that professionals do. That results in an odd combination
of things that I do know and things that I don't know. Sometimes that is an
advantage, sometimes not.

I own (the original) K&R and I use it. But I prefer to use ANSI C, so I
rely more often on Harbison and Steele.

Since you think that this web page is so useful, can you please quote the
precise part of the web page that says explicitly that

int (*foo)() { /* blah */ }

is wrong? Alternatively, can you construct a proof that it is wrong using
sentences on that web page as axioms? I think that will provide some measure
of the aptness of this web page as a reference for the present discussion.

I'd also like to point out that I did realize that there was something
wrong with the declaration I was dealing with. Knowing that it is wrong
and knowing which of the many possible syntactically correct expressions to
put in its place are two entirely different things. My question was aimed
at the latter problem. Your remarks seem to be aimed at the former.

The art of being able to diagnose someone else's misunderstandings and
ignorance and to figure out exactly what they need in order to understand
a particular thing that they want to learn is the art of the educator. It
takes a lot of experience and a lot of patience. In particular, it takes a
willingness to observe and to ask questions before rushing in with
prescriptive advice. I sense from what you write that you do like to
explain things, that you are enthusiastic about the subject that we are
discussing and that you don't entirely know what to do with these tendencies.
Maybe someday you will become a computer science professor, if you aren't
already. But at some point, you will need to learn something fundamental
about teaching, which is that everyone who seeks to learn has his own history,
his own needs, his own abilities and disabilities and his own unique way of
learning and you will have to learn how to be sensitive to these things.
I can't give you any specific advice about that, especially since I don't
know you, but I do wish you luck with it, both for your own sake and for the
sake of your students.
--
Ignorantly,
Allan Adler <ara@xxxxxxxxxxxxxxxxxxxx>
* Disclaimer: I am a guest and *not* a member of the MIT CSAIL. My actions and
* comments do not reflect in any way on MIT. Also, I am nowhere near Boston.
.