Jump to content


Check out our Community Blogs

Register and join over 40,000 other developers!


Recent Status Updates

View All Updates

Photo
- - - - -

Pointers!

pointers objects variables memory arrays arithmetic c++ c address

  • Please log in to reply
30 replies to this topic

#13 object

object

    CC Regular

  • Member
  • PipPipPip
  • 35 posts
  • Programming Language:C, C#, JavaScript

Posted 06 January 2013 - 10:20 PM

Ritwik: An uninitialised variable has an undefined or indeterminate value; Using such a value is always bad news. It doesn't matter if it seems to do something on your system. The moment you use something undefined, you're not programming in C or C++ any more, because you're violating the rules.

I think for the level of this tutorial, its fine. There's nothing wrong with simplifing things - if all we did was say read the standard, nobody would learn C or C++.

There is no need to teach people to use undefined behaviour (eg. by telling them all pointers are the same size). That's not simplifying things; It's making things worse. That's like teaching someone all liquids are the same, and bleach can be used in place of water. If people made an effort to read and understand the standard, they would surely learn how to write portable C or C++ code. How else are they going to learn, if not by reading? Closing their eyes and blindly mashing at the keyboard, hmmm?

Most people would automatically assume they could do &a = x;

Precisely. That is why I suggested reminding students of the relationship between object and value. value = value; doesn't make sense. &a is a value, not an object. That's all it takes to cover this problem.

Yannbane: I would like to quote again from the standard, section 6.3.2.1 point 3: Except when it is the operand of the sizeof operator, the _Alignof operator, or the unary & operator, or is a string literal used to initialize an array, an expression that has type ‘‘array of type’’ is converted to an expression with type ‘‘pointer to type’’ that points to the initial element of the array object and is not an lvalue.


This is relevant for two reasons:
1. It explicitly states that the sizeof, _Alignof and &address-of operators function differently for array expressions than pointer expressions, and thus a pointer is not an array.
2. It demonstrates the use of the words "pointer to type" in the context of expressions that aren't modifiable. I think it's accurate to use the term "values" in this context. Is this type of expression "just another variable, which can contain a memory address of any other variable or object", as you wrote? If not, then that is an inaccurate description of the term "pointer".

In addition to point 2, consider the return value of malloc: "The malloc function returns either a null pointer or a pointer to the allocated space." (n1570.pdf, section 7.22.3.4).
Is a null pointer a "variable which can contain a memory address"? What about the return value of malloc, eg. malloc(42)? Is that a "variable which can contain a memory address of any other variable or object"? It doesn't seem difficult to reiterate the relationship between objects and values, and state that pointer objects can store pointer values.
The standard seems to give the impression that:
i. A pointer value may or may not point to an object. For example, &x points to x, but null pointers do not point to objects.
ii. An address is a pointer value that points to an object. Thus, &x is an address but null pointers are not.

In summary, it is appropriate to refer to &x as either a pointer (implying "pointer value") or an address. It is not appropriate to refer to &x as a "variable which can contain a memory address of any other variable or object".

Edited by object, 06 January 2013 - 10:26 PM.

  • 0

#14 0xDEADBEEF

0xDEADBEEF

    CC Devotee

  • Senior Member
  • PipPipPipPipPipPip
  • 790 posts
  • Programming Language:C, Java, C++, C#, (Visual) Basic, Perl, Transact-SQL, Bash, Prolog, Others
  • Learning:Others

Posted 07 January 2013 - 03:23 AM

Hah, way to missquote and misunderstand.

Firstly:

I think for the level of this tutorial, its fine. There's nothing wrong with simplifing things - if all we did was say read the standard, nobody would learn C or C++.

There is no need to teach people to use undefined behaviour (eg. by telling them all pointers are the same size). That's not simplifying things; It's making things worse. That's like teaching someone all liquids are the same, and bleach can be used in place of water. If people made an effort to read and understand the standard, they would surely learn how to write portable C or C++ code. How else are they going to learn, if not by reading? Closing their eyes and blindly mashing at the keyboard, hmmm?


My quote was refering the post immediatly above it. This was saying that the phrase - a pointer is a variable. Was fine for this level of tutorial. I wasn't refering to using underfined behaviour nor the size / alighment of pointers. Things like alignment are not beginner topics.

I'm not saying learners shouldn't read, I'm saying that beginners shouldn't read the specification as their first port of call.

Would you give a 5 year old principal mathematica and expect them to understand all of maths? Would you teach special relativity before the ideas of Newton?

Most people would automatically assume they could do &a = x;


Maybe if you used the whole sentence, you'd see that I said:

So I wouldn't assume that, given the correct explaination of &, i.e it gives the address of the variable, not it gives a pointer to the variable. Most people would automatically assume they could do &a = x;

Maybe poor english, but this was ment to say; given the correct explaination of &, you can't assume that most people would automatically think they could do &a = x.
  • 0

Creating SEGFAULTs since 1995.


#15 Yannbane

Yannbane

    CC Addict

  • Advanced Member
  • PipPipPipPipPip
  • 238 posts
  • Programming Language:C, Java, C++, PHP, Python, JavaScript, PL/SQL, Lisp, Assembly, Bash, Others
  • Learning:Lisp, Scheme

Posted 07 January 2013 - 06:25 AM

There is no need to teach people to use undefined behaviour (eg. by telling them all pointers are the same size). That's not simplifying things; It's making things worse. That's like teaching someone all liquids are the same, and bleach can be used in place of water. If people made an effort to read and understand the standard, they would surely learn how to write portable C or C++ code. How else are they going to learn, if not by reading? Closing their eyes and blindly mashing at the keyboard, hmmm?


I've edited the tutorial already. I think you're overreacting a bit though, on most systems it is safe to assume that pointers are of the same size, and the fact that stating that they are so gets the point across and eliminates potential ambiguity is important. It is a simplification, and a useful one. Pointer size should not be a concern to anyone reading this tutorial, nor should this tutorial be the only source of knowledge to anyone who finds the size of pointers important, if they're programming something so detailed they might as well read the standard and not a tutorial, because there's a big difference between those two.

Precisely. That is why I suggested reminding students of the relationship between object and value. value = value; doesn't make sense. &a is a value, not an object. That's all it takes to cover this problem.


You're intentionally misunderstanding: I have never stated that &a is a value. I have clearly explained that &a is the adress of the variable a, there is no ambiguity about this and you should stop bringing this up.

1. It explicitly states that the sizeof, _Alignof and &address-of operators function differently for array exp<b></b>ressions than pointer exp<b></b>ressions, and thus a pointer is not an array.


No, it's not, however int ** matrix can behave like an array and I have seen it do so in more examples than not. But there's no reason to bring this up again.

2. It demonstrates the use of the words "pointer to type" in the context of exp<b></b>ressions that aren't modifiable. I think it's accurate to use the term "values" in this context. Is this type of exp<b></b>ression "just another variable, which can contain a memory address of any other variable or object", as you wrote? If not, then that is an inaccurate description of the term "pointer".


Saying that x in int * x; is a pointer is good enough for a tutorial. "Pointer" is an ambiguous term which can mean multiple things (a type, a value, a variable). Again, this tutorial concerns the actual concept of a pointer, and the definitions I gave are good enough.

Is a null pointer a "variable which can contain a memory address"? What about the return value of malloc, eg. malloc(42)? Is that a "variable which can contain a memory address of any other variable or object"?


integer - as in the type 'int'
integer - as x in int x;, as in "x is an integer", as in "this variable is an integer"
integer - as in "this function returns an integer"

I hope you realize that these terms can mean different things depending on the context, and thus my usage of "pointer" was acceptable. You recognize this ambiguity by differentiating between "pointer type" and "pointer value". I refer to pointers mostly as types, and thus I believe it is OK to state e.g. "x is a pointer" where x is a variable, just as it is OK to state e.g. "y is an integer", where y is a variable of type int. Again, this has already been explained.

The kind of precision you seem to be advocating is definitely suitable and required for a standard, but not for a beginner-level tutorial.
  • 1

My blog: yannbane.com. I post about programming, game development, and artificial intelligence.


#16 Ritwik I the programmer

Ritwik I the programmer

    CC Addict

  • Advanced Member
  • PipPipPipPipPip
  • 244 posts
  • Programming Language:Java
  • Learning:Java, C++, Python

Posted 08 January 2013 - 08:31 AM

would this be a valid if condition?:

int *x = NULL;
if(x == NULL)
{
    //Some Code
    //.........
}

  • 0

I can believe, but why should I?


#17 0xDEADBEEF

0xDEADBEEF

    CC Devotee

  • Senior Member
  • PipPipPipPipPipPip
  • 790 posts
  • Programming Language:C, Java, C++, C#, (Visual) Basic, Perl, Transact-SQL, Bash, Prolog, Others
  • Learning:Others

Posted 08 January 2013 - 09:21 AM

Yes.
  • 2

Creating SEGFAULTs since 1995.


#18 object

object

    CC Regular

  • Member
  • PipPipPip
  • 35 posts
  • Programming Language:C, C#, JavaScript

Posted 08 January 2013 - 07:16 PM

You're intentionally misunderstanding: I have never stated that &a is a value. I have clearly explained that &a is the adress of the variable a, there is no ambiguity about this and you should stop bringing this up.

I'm not misunderstanding; The quote you were responding to here was a response to someone else. The word "should" implies obligation. Am I obliged to ignore other people? That'd be rude...

The kind of precision you seem to be advocating is definitely suitable and required for a standard, but not for a beginner-level tutorial.

Inaccuracy due to omissions or summarising for the point of simplicity is understandable. Stating incorrect assumptions as fact is something completely different. I've pointed the errors out to you, and you seem to be reluctant to change them. Why not try a little bit of humble pie? Would you prefer to leave your errors uncorrected, for us to gawk at? I don't enjoy cleaning up messes caused by these assumptions. Clean up your own mess!

I shall now analyse your tutorial, since you have modified it.

A pointer is a just another variable, which can contain a memory address of any other variable or object.

In that case, the pointer returned by malloc(0) can contain a memory address of any other variable or object. Furthermore, "bus error" is non-existant.

A pointer to an integer and a pointer to your Humanoid object do not actually differ in size most of the time

Suppose I typedef char Humanoid;. This page now contradicts your statement: "Older, word-addressed Prime machines were also notorious for requiring larger byte pointers (char *'s) than word pointers (int *'s)."

Quoting yourself, "Pointer size should not be a concern to anyone reading this tutorial". If pointer size should not be a concern to anyone reading this tutorial, then I fail to see why you mention it to begin with. Surely it'd be a much less ambiguous "simplification" to remove the erroneous statements...

Edited by object, 08 January 2013 - 07:28 PM.

  • 0

#19 Yannbane

Yannbane

    CC Addict

  • Advanced Member
  • PipPipPipPipPip
  • 238 posts
  • Programming Language:C, Java, C++, PHP, Python, JavaScript, PL/SQL, Lisp, Assembly, Bash, Others
  • Learning:Lisp, Scheme

Posted 09 January 2013 - 02:31 AM

Attack the explanations in my last post, not the OP, because you've already done that. If you continue to simply ignore my responses to your attacks, the discussion cannot move on.

Not to mention how you're basing your argumentation on apparently not seeing the big bold words most of the time and an ambiguous use of the word "pointer" (type, variable, value).

I'll edit "A pointer is just..." into "A pointer variable is just..." to reduce said ambiguity.
  • 0

My blog: yannbane.com. I post about programming, game development, and artificial intelligence.


#20 object

object

    CC Regular

  • Member
  • PipPipPip
  • 35 posts
  • Programming Language:C, C#, JavaScript

Posted 09 January 2013 - 03:43 AM

Bolding is for advertisements and attention seekers. I'd suggest learning how to express your point without having to use bold. Your point seems to be that you're attempting to "eliminate potential ambiguity". How is that achieved by lying to people?

A pointer variable is a just another variable, which can contain a memory address of any other variable or object.

Good. That's a bit less ambiguous, but this still encourages bus errors.

Your assertion that a "pointer to Humanoid" is the same size as a "pointer to int" is a bit like saying "bleach looks and smells like vinegar". Adding the precondition "most of the time" to that statement doesn't help. Imagine how society would be if we didn't learn that lesson, to warn people about the green potatoes, or to put warning labels on the bleach? Care for some bleach with your french fries?!

Did you know that there have been massive lawsuits over software that was poorly written? People have been killed, because someone assumed that "this program worked on previous systems, it'll work on the new one". If you're not willing to learn and adapt to changes, then you don't belong in the IT industry. Have you ever considered marketting?

You stated that the size of pointers is irrelevant to the tutorial. In that case, why mention the size of the pointers in your tutorial? My suggestion was to remove the irrelevant content. You appear reluctant, and so I feel obliged to remain on your case for the sake of the poor souls you're misleading. Let us know when you've rectified your errors.

Edited by object, 09 January 2013 - 03:47 AM.

  • 0

#21 0xDEADBEEF

0xDEADBEEF

    CC Devotee

  • Senior Member
  • PipPipPipPipPipPip
  • 790 posts
  • Programming Language:C, Java, C++, C#, (Visual) Basic, Perl, Transact-SQL, Bash, Prolog, Others
  • Learning:Others

Posted 09 January 2013 - 05:14 AM

Le sigh
  • 1

Creating SEGFAULTs since 1995.


#22 Yannbane

Yannbane

    CC Addict

  • Advanced Member
  • PipPipPipPipPip
  • 238 posts
  • Programming Language:C, Java, C++, PHP, Python, JavaScript, PL/SQL, Lisp, Assembly, Bash, Others
  • Learning:Lisp, Scheme

Posted 09 January 2013 - 06:44 AM

Good. That's a bit less ambiguous, but this still encourages bus errors.

Do explain, I'll edit it again if it's something important.

Bolding is for advertisements and attention seekers.

Well that's the point. I want attention to be paid to that particular part of the sentence, that's why I've bolded it.

pointers are of the same size most of the time - wont hurt anyone completely new to pointers, will remind them to check out whether they're really of the same size if they're working with esoteric architectures, and it gets the point across, which is why it is relevant to a beginner tutorial.

I wont even reply to you anymore if you don't bring in something new to the discussion.

(On a side note, I better put a giant red disclaimer that I take no responsibility for any murders which my tutorial might have caused.)
  • 1

My blog: yannbane.com. I post about programming, game development, and artificial intelligence.


#23 object

object

    CC Regular

  • Member
  • PipPipPip
  • 35 posts
  • Programming Language:C, C#, JavaScript

Posted 09 January 2013 - 09:54 PM

Well, I posted a link regarding bus errors. Did you read that link? It is very important, otherwise I wouldn't have mentioned it.

You've bolded your justification, which indicates that you missed my point: undefined behaviour. This means that code based on your incorrect assumptions is not required to work, at all, on perfectly valid C or C++ implementations. I wouldn't bring any of this up if you weren't encouraging people to invoke undefined behaviour.

Given a perfectly valid C or C++ implementation where a pointer to Humanoid differs in size from a pointer to int, a pointer to Humanoid will always differ in size to a pointer to int; To insist that they are equal "most of the time" is nonsense. See my previous posts for a real life example. Adding "most of the time" doesn't make your statement any more valid, or less ambiguous.

Edited by object, 09 January 2013 - 09:56 PM.

  • 0

#24 0xDEADBEEF

0xDEADBEEF

    CC Devotee

  • Senior Member
  • PipPipPipPipPipPip
  • 790 posts
  • Programming Language:C, Java, C++, C#, (Visual) Basic, Perl, Transact-SQL, Bash, Prolog, Others
  • Learning:Others

Posted 10 January 2013 - 12:16 AM

A pointer variable is a just another variable, which can contain a memory address of any other variable or object.


Thinking about this some more this is fine for an entry level tutorial. Bus errors come when you try access data that is incorrectly aligned. This will happen if you take say a char[4] array then attempt to convert a pointer to an int pointer on it.

But the statement above just says that a pointer can contain a memory address of any other variable or object. Given that its not saying, we can pretend data is something else. This is fine, if I take a perfectly aligned variable and then take its address. This won't give a bus error. If I attempt to refer to it as the wrong type it might do. But that's not what the statement says; that line is fine.

Now onto the size issue; you have given numorious examples of machines in which pointer sizes are different. Most of these appear to be >20 years old. Tbh, 99.999999999% of people learning this language will do so on a modern x86 processor. So really the tutorial should be correct on that platform.


In regard to the Therac-25 issue; the failure there wasn't pointers, but a lack of testing. I'm not sure how this tutorial is advocating a lack of testing? I mean the problem was the hardware changed - an interlock was removed - which exposed an existing software bug. I think if the software had crashed with a bus error then nobody would have actually died.
  • 0

Creating SEGFAULTs since 1995.






Also tagged with one or more of these keywords: pointers, objects, variables, memory, arrays, arithmetic, c++, c, address

Recommended from our users: Dynamic Network Monitoring from WhatsUp Gold from IPSwitch. Free Download