On 10/10/07, Jenda Krynicky <[EMAIL PROTECTED]> wrote: > > From: yitzle <[EMAIL PROTECTED]> > > On 10/10/07, Jenda Krynicky <[EMAIL PROTECTED]> wrote: > > > > Anyhow, the point is that Perl doesn't have those confusing weird > > > "pointer" > > > > stuff. $a and $c do not "point" to the same place, the just got the > same > > > > value. (Well, Perl /does/ have pointers, but... whatever.) > > > > > > Yeah, it does seem you are pretty confused by pointers in C. And > > > probably by references in Perl too. I wonder how can you program > > > without understanding pointers/references, but whatever. > > > > > > Jenda > > > > > > The purpose of my message was to clarify the part of the documentation > that > > Kaushal asked about. > > I think you failed on that.
I would think that Kaushal would be the one making that decision. In case you did not understand, the clarification was made for Kaushal, not you. I fail to see how you can judge whether my message to someone else achieved its purpose. And even supposing Kaushal did notify you that my message did not achieve its goal, you had no way of knowing this prior to being told. I'd think it is better to try to explain a matter than not explain at all for fear the explanation may not achieve its goal. I'd also like to point out that I fail to see how your message helps anyone out. Did you attempt to clarify the matter? Did you attempt to be helpful? You made judgement calls that were both wrong and not based on a good source of knowledge. Judgement calls like that are not only not helpful, but /are/ better kept unsaid. Unlike an attempt to help out. > I am aware that Perl has pointers/references, as I mentioned, but the > > question is not /about/ pointers, but variables. > > Then why did you start about C pointers? Why the C at the all? The > int variables in C work exactly the same scalars work in Perl and the > C pointers work (almost) exactly the same as the references in Perl. It was to heighten the contrast. I am sorry you had issues understand this. Maybe the person I intended to aid also misunderstood the same idea.. Or maybe not, in which case my message achieved its intended purpose. If it didn't help, other people might help Kaushal out. They might follow my lead and do a better job clarifying what a pointer is; in that case, my message was useful in illustrating how the matter can be clarified. Or maybe my message was of no use. I think its fair to say judgement calls of a person's knowledge that are false or even not based on any good knowledge tend to be of no use... And BTW ... you are aware of the fact that if you do > > int *b; > *b = 5; > > you cause the program to crash, right? > You did not start by assigning a variable to a reference to > something, you assigned to the thing already referenced by a > variable. And unlike Perl, C doesn't "autovivify" the pointer. It > doesn't notice that the b doesn't point to anything yet and doesn't > initialize the pointer. And will try to access the address 0. Yes, I am aware. Are you aware that the purpose of my email was not to give working code, but to explain a concept? Is it so important that the code be current to the point of not achieving its purpose? Because if I did get detailed, my message would have had a lesser chance of being helpful by being more confusing. If you need evidence, I can supply you with ample working C code I wrote. I can also supply Perl code, if I require evidence to post to this group in an attempt to help out members. Can you supply evidence of your messages being helpful in the past? > The documentation seems to be contrasting variables to pointers. Rather > than > > introducing perl references, I thought I could use a bit of C to explain > how > > it is possible that by changing $b, you affect $a, and then say with > normal > > Perl variables (I know, the word "normal" is wrong) do not exhibit this > > behavior. > > This might make some sense if Kaushal knew C already. And I don't > think it's the case. Very good! Exactly why I didn't bother get detailed. It was only intended to illustrate a concept! But how can you not be sure whether Kausal knows C or not when you can tell whether Kaushal found my reply helpful? > I was trying to avoid being overly technical and trying to explain the > > concept in a way that someone unfamiliar with pointers or references > would > > be able to understand them. > > > > How did my code indicate to you that I am confused about C pointers? It > > looks pretty correct to me... > > And Perl references? I mention they exist, but tried avoiding talking > about > > them in this explanation. I use references and pointers in programming, > but > > in this explanation, I believe I dealt with them correctly. > > It was not so much the code, but the comments. That may be the case. Does it matter? Jenda > This email raises a matter that I often see that bothers me. Forgive me if I am out of bounds, but often someone who is just starting out with a new language or concept asks a question to clarify something. Sometimes the only answer is a complex answer. But at other times, a simple answer exists. Why do people seem to prefer giving the more complex answer? The person usually wants a simple solution, not proof that you can write complex simple line programs. And why, when code is given to explain a concept, to people have to analyze the code and pinpoint all the problems it has? An example does not need to work. It demonstrates an idea! Its not meant to be compiled or ran. - yitzle
