Re: "Mastering C Pointers"....

From: Roose (nospam_at_nospam.nospam)
Date: 11/03/03 

Date: Mon, 03 Nov 2003 00:27:32 GMT

> > Give me a break.
>
> Sure. Take a break, any time you like.

Hilarious. Back to children's games, I see.

> In comp.lang.c.moderated, I suspect that many of your articles would
simply
> not be approved by the moderator. Feel free to try to prove me wrong.

As would many of yours.

> > filled with irrelevant technical details,
>
> You may consider the details irrelevant. I do not, however, pitch my
answers
> at your level of understanding, but at the questions actually asked by
real
> people. When the details matter, I give the details. When they don't, I
> don't. Now, you may have considered my answer to be overly technical, but
> it's a walk in the park compared to the answer I /could/ have given. I
> included as much detail as I considered the OP could reasonably be
expected
> to take in (in one sitting), together with a little encouragement that it
> really isn't as hard as he's been led to believe. I continue to maintain
> that this was an appropriate response to his question.

I'm not talking about your pointer response, which was generally good, as I
already said. I'm talking about the newsgroup in general. Read some of the
responses to newbies. See how helpful they are.

Even the first one in this thread was quite unhelpful. The guy was like "I
heard it was about Turbo C and MS-DOS -- that means you shouldn't read
it." -- with no further explanation. Do you think a newbie knows what that
means, or knows what Turbo C is (or even DOS)? A much more helpful response
would be along the lines of, "This book appears to be rooted in a particular
platform, one that happens to be outdated, and thus may confuse you with a
lot of information that you don't need to know."

> > which you would never hear in the real world.
>
> Well, actually, I do discuss such (relevant) technical details in the real
> world, as well as on Usenet. And anyway, what makes you think that Usenet
> is not part of the real world?

Stop with the sniveling wordplay already.

> > Then they
> > get turned off to C and think it's for wankers.
>
> Speculation. I've found that people often respond well to being told the
> underlying truth, rather than the helicopter-joystick method of
> programming: "fiddle with the program, and watch what the computer does,
> because if you want it to do that again, that is the code you have to
> write" is not a very satisfactory way to learn programming.

I agree that that's a terrible way to learn. Without the concepts, you're
just blindly hacking. That's why I specifically said that you need at least
TWO perspectives. I encourage them to read your article. My claim is that
that's not sufficient. They should read a concrete explanation like mine.
Together they will help you understand pointers.

Plus my article encouraged them to learn the abstract while being rooted in
the concrete, not to focus on the concrete at the expense of the abstract.

This is exactly like the top-post thread. You're so goddamn close-minded
that you think the only way to do everything is your own. I, on the other
hand, recognize that sometimes things needs multiple perspectives, and there
are multiple valid ways of doing things. Sometimes there is no right and
wrong, just personal preference. I know it's a lot to handle, since you
like rigid rules so much.

> > obscures the real question. Getting a job, or learning how
> > to write a real program that does what you want it to do.
>
> That wasn't the real question. The real question was about pointers.

OK, so do you think that the OP wanted just to study pointers for the sake
of dinner party conversation, or eventually write a real program? Again,
READ BETWEEN THE LINES. Jesus Christ.

> > It may technically, but not in colloquial usage.
>
> Then colloquial usage is wrong, and should be changed.

Q.E.D. Another perfect example of why my underemployed flames were so
accurate. Everybody else is wrong; and you're right. Yes. You can insist
on using the term object however you want. However the rest of the world
will continue to use a more useful definition. I guess Stroustrop and
Ritchie and all the people who use the term OOP are wrong. Since, of
course, by default you should assume when someone says "object" in C++, they
mean something that takes storage, and not something with a constructor and
destructor and all that.

Let me suggest that you are the one who needs to change.

> >> Wrong. It's a *vital* word for those who wish truly to understand C.
> >
> > Maybe for understanding the C standard. It is not vital for those who
> > simply wish to write successful programs,
>
> If one wishes to write /correct/ C programs, an understanding of the
> principles laid out in the Standard is vital. The easiest way to achieve
> this understanding is by reading and understanding the C Standard.

What percent of the total number of C programs in the world do you think are
correct in this sense?

Was your first C program correct in this sense? Would it have taken more
time and effort to make it correct, knowing what you knew then? What do you
think the OP is interested in doing, _at this stage in the game_? Do think
he is interested in reading the C standard, before having written anything
substantial or understanding pointers at a practical level?

No sarcasm there, just answer honestly.

Roose

Relevant Pages

  • Re: Reading explicitly package-qualified symbols?
    ... >> I was just trying to confirm that understanding when I discovered I ... >> couldn't track it down in the standard. ... Any pointers to the chapter ... -- John Fraser, comp.lang.lisp ...
    (comp.lang.lisp)
  • Re: Fakta: Subyektif atau Obyektif?
    ... Why is your understanding so poor? ... response and come back to explain what is the content ... Standard reply from mbill when he cannot provide a decent ...
    (soc.culture.indonesia)
  • Re: Can I trust a vector to stay put if I dont add to it?
    ... > My understanding of the containers in the Standard Library is that they ... > move out from under pointers and references if they are resized. ... I have the sense this is not explicitly specified in the Standard. ...
    (comp.lang.cpp)
  • Re: Very unusual WR for Lenton
    ... The question is whether drafting and the amount of "assistance" ... has no viable referenced support. ... You're the one who's dumber than anyone thought by not understanding ... response in this inane thread. ...
    (rec.sport.swimming)
  • Re: "<>", a relational operator?
    ... And in Standard C there are significant restrictions ... OTOH in BCPL and B pointers were ... has no whole array operations; if you want something done to all (or ... the Standard isn't vague at all -- this is specifically ...
    (comp.lang.fortran)