Good Tutorials

Discussion in 'C Programming' started by Amkcoder, Sep 23, 2008.

  1. Amkcoder

    Amkcoder Guest

    1. Advertising

  2. Amkcoder

    MisterE Guest


    > "A pointer in C is a variable which holds the address of another variable
    > in memory. They are useful for dynamicly allocated memory which may be
    > deallocated when nolonger needed,linked lists,writing to memory external to
    > the program,and allowing invoked functions to manipulate the data of
    > variables outside their scope. These have many uses and are necessary to
    > successfull programming in C."
    >
    > Oh deary deary me.


    Yeah sounds like its written for people who actually want to get stuff
    done, instead of written for people who want to be anal over definitions.
     
    MisterE, Sep 23, 2008
    #2
    1. Advertising

  3. Richard Heathfield <> writes:

    > MisterE said:
    >
    >>
    >>> "A pointer in C is a variable which holds the address of another
    >>> variable in memory. They are useful for dynamicly allocated memory which
    >>> may be deallocated when nolonger needed,linked lists,writing to memory
    >>> external to the program,and allowing invoked functions to manipulate the
    >>> data of variables outside their scope. These have many uses and are
    >>> necessary to successfull programming in C."
    >>>
    >>> Oh deary deary me.

    >>
    >> Yeah sounds like its written for people who actually want to get stuff
    >> done, instead of written for people who want to be anal over definitions.

    >
    > People who take the time to learn their subject properly are more likely to
    > get more stuff done more quickly than people who just grab a screwdriver
    > and start poking around at random.
    >
    > Ignoring, if I may, the appalling wordsmithery, I count three errors of
    > fact in that first paragraph.


    I count only 2 and half. Why not tell us your three[1]?

    Interesting fact from my teaching: I'd explain some concept to student
    A carefully using all the right terms. Because both the concept and
    terms are new, students A looks a little baffled. Before I can have
    another go, student B -- listen in -- repeats what I have said in
    different (more common) words thereby introducing several technical
    errors. Student A goes "Ah, I get it" and repeats it using yet more
    terms with yet more errors of fact. I used not to walk away in my
    early years but I soon learnt it was better to walk away saying
    "that's the gist of it" and making a note to correct some of the
    technical details later.

    Now, a tutorial is different, but it may later correct this sloppy
    start.

    [1] Mine are: a pointer is a value not a variable. They address
    objects not variables (that, to me, is the half) and I don't like the
    idea of "memory external to the program". If you have a pointer you
    can write though, it is your data (even if the OS wishes it were
    not!).

    --
    Ben.
     
    Ben Bacarisse, Sep 23, 2008
    #3
  4. Amkcoder

    Bartc Guest

    "Richard Heathfield" <> wrote in message
    news:...
    > Ben Bacarisse said:
    >
    >> Richard Heathfield <> writes:


    >>> Ignoring, if I may, the appalling wordsmithery, I count three errors of
    >>> fact in that first paragraph.

    >>
    >> I count only 2 and half. Why not tell us your three[1]?
    >>

    > <snip>
    >>
    >> [1] Mine are: a pointer is a value not a variable. They address
    >> objects not variables (that, to me, is the half) and I don't like the
    >> idea of "memory external to the program". If you have a pointer you
    >> can write though, it is your data (even if the OS wishes it were
    >> not!).

    >
    > One of yours (the first one), and my second is a rather harsher take on
    > the
    > same subject as your one-and-a-halfth point, because pointer values need
    > not even represent object addresses, let alone variable addresses - they
    > could be indeterminate, or null, or function pointers. My third rather
    > depends on what you mean by "variable", but if the last clc discussion on
    > the matter is anything to go by, the bit about scope is wrong too.


    This is exactly the point MisterE was making.

    I neither know nor care whether a pointer is a value, variable, type or
    object. But that hasn't stopped me using them quite effectively.

    --
    Bartc
     
    Bartc, Sep 23, 2008
    #4
  5. Amkcoder

    Amkcoder Guest

    On Sep 23, 6:49 am, Ben Bacarisse <> wrote:
    > Richard Heathfield <> writes:
    > > MisterE said:

    >
    > >>> "A pointer in C is a variable which holds the address of another
    > >>> variable in memory. They are useful for dynamicly allocated memory which
    > >>> may be deallocated when nolonger needed,linked lists,writing to memory
    > >>> external to the program,and allowing invoked functions to manipulate the
    > >>> data of variables outside their scope. These have many uses and are
    > >>> necessary to successfull programming in C."

    >
    > >>> Oh deary deary me.

    >
    > >> Yeah sounds like its written for people who actually want to get stuff
    > >> done, instead of written for people who want to be anal over definitions.

    >
    > > People who take the time to learn their subject properly are more likely to
    > > get more stuff done more quickly than people who just grab a screwdriver
    > > and start poking around at random.

    >
    > > Ignoring, if I may, the appalling wordsmithery, I count three errors of
    > > fact in that first paragraph.

    >
    > I count only 2 and half. Why not tell us your three[1]?
    >
    > Interesting fact from my teaching: I'd explain some concept to student
    > A carefully using all the right terms. Because both the concept and
    > terms are new, students A looks a little baffled. Before I can have
    > another go, student B -- listen in -- repeats what I have said in
    > different (more common) words thereby introducing several technical
    > errors. Student A goes "Ah, I get it" and repeats it using yet more
    > terms with yet more errors of fact. I used not to walk away in my
    > early years but I soon learnt it was better to walk away saying
    > "that's the gist of it" and making a note to correct some of the
    > technical details later.
    >
    > Now, a tutorial is different, but it may later correct this sloppy
    > start.
    >
    > [1] Mine are: a pointer is a value not a variable. They address
    > objects not variables (that, to me, is the half) and I don't like the
    > idea of "memory external to the program". If you have a pointer you
    > can write though, it is your data (even if the OS wishes it were
    > not!).
    >
    > --
    > Ben.


    The definition you so waywardly complain about is repeated as a common
    definition:
    "A pointer is a variable that points at, or refers to, another
    variable."
    http://www.eskimo.com/~scs/cclass/notes/sx10.html, even at
    universities.
    Using memory external to a program, is sometimes also necessary, like
    writing directly to video memory, or using the DOS inter application
    communication
    are, are is said here:
    http://www.osdata.com/system/physical/lowmem.htm#usercommo

    ARE YOU GUYS EVEN PROGRAMMERS?
    You could not point out why when you said I was wrong.

    Like I said, good tutorials...
    Please only sincere students or real programmers comment,
    others just waste space...
     
    Amkcoder, Sep 23, 2008
    #5
  6. Amkcoder

    Amkcoder Guest

    On Sep 23, 6:49 am, Ben Bacarisse <> wrote:
    > Richard Heathfield <> writes:
    > > MisterE said:

    >
    > >>> "A pointer in C is a variable which holds the address of another
    > >>> variable in memory. They are useful for dynamicly allocated memory which
    > >>> may be deallocated when nolonger needed,linked lists,writing to memory
    > >>> external to the program,and allowing invoked functions to manipulate the
    > >>> data of variables outside their scope. These have many uses and are
    > >>> necessary to successfull programming in C."

    >
    > >>> Oh deary deary me.

    >
    > >> Yeah sounds like its written for people who actually want to get stuff
    > >> done, instead of written for people who want to be anal over definitions.

    >
    > > People who take the time to learn their subject properly are more likely to
    > > get more stuff done more quickly than people who just grab a screwdriver
    > > and start poking around at random.

    >
    > > Ignoring, if I may, the appalling wordsmithery, I count three errors of
    > > fact in that first paragraph.

    >
    > I count only 2 and half. Why not tell us your three[1]?
    >
    > Interesting fact from my teaching: I'd explain some concept to student
    > A carefully using all the right terms. Because both the concept and
    > terms are new, students A looks a little baffled. Before I can have
    > another go, student B -- listen in -- repeats what I have said in
    > different (more common) words thereby introducing several technical
    > errors. Student A goes "Ah, I get it" and repeats it using yet more
    > terms with yet more errors of fact. I used not to walk away in my
    > early years but I soon learnt it was better to walk away saying
    > "that's the gist of it" and making a note to correct some of the
    > technical details later.
    >
    > Now, a tutorial is different, but it may later correct this sloppy
    > start.
    >
    > [1] Mine are: a pointer is a value not a variable. They address
    > objects not variables (that, to me, is the half) and I don't like the
    > idea of "memory external to the program". If you have a pointer you
    > can write though, it is your data (even if the OS wishes it were
    > not!).
    >
    > --
    > Ben.


    The definition you so waywardly complain about is repeated as a common
    definition:
    "A pointer is a variable that points at, or refers to, another
    variable."
    http://www.eskimo.com/~scs/cclass/notes/sx10.html, even at
    universities.
    Using memory external to a program, is sometimes also necessary, like
    writing directly to video memory, or using the DOS inter application
    communication
    are, are is said here:
    http://www.osdata.com/system/physical/lowmem.htm#usercommo

    ARE YOU GUYS EVEN PROGRAMMERS?
    You could not point out why when you said I was wrong.

    Like I said, good tutorials...
    Please only sincere students or real programmers comment,
    others just waste space...
     
    Amkcoder, Sep 23, 2008
    #6
  7. Amkcoder

    Guest

    On Sep 23, 6:09 pm, "Bartc" <> wrote:

    <snip>

    > I neither know nor care whether a pointer is a value, variable, type or
    > object. But that hasn't stopped me using them quite effectively.


    I doubt you've used pointers effectively.

    Message-ID: <Xzryk.56633$>
    Bartc said:
    > vippstar said:
    >> Given that p is char [4][2], you should immediately be able to tell
    >> which type *p is, p[0][0], &p[0].
    >> (answer: char [2], char, char (*)[2])

    >
    > I wouldn't frighten off the OP with this stuff. I don't understand half of
    > it either.


    Now, if you don't understand types, and those who are so trivial, I
    doubt you can use pointers effectively.
    Even if you can, it was by luck. You certainly *can't* write a
    tutorial about using pointers effectively, or pointers in general.
     
    , Sep 23, 2008
    #7
  8. Amkcoder

    Amkcoder Guest

    On Sep 23, 8:33 am, wrote:
    > On Sep 23, 6:09 pm, "Bartc" <> wrote:
    >
    > <snip>
    >
    > > I neither know nor care whether a pointer is a value, variable, type or
    > > object. But that hasn't stopped me using them quite effectively.

    >
    > I doubt you've used pointers effectively.
    >
    > Message-ID: <Xzryk.56633$>
    > Bartc said:
    >
    > > vippstar said:
    > >> Given that p is char [4][2], you should immediately be able to tell
    > >> which type *p is, p[0][0], &p[0].
    > >> (answer: char [2], char, char (*)[2])

    >
    > > I wouldn't frighten off the OP with this stuff. I don't understand half of
    > > it either.

    >
    > Now, if you don't understand types, and those who are so trivial, I
    > doubt you can use pointers effectively.
    > Even if you can, it was by luck. You certainly *can't* write a
    > tutorial about using pointers effectively, or pointers in general.


    Why don't you explain why I am wrong then, MR.PROGRAMMER,
    and just to tell you my understanding of datatypes is backed
    by the intel x86 manuals applications programming section,
    chapter on data types.

    So you call Intel liars,
    You call universities who use my same definition of pointers liars,
    And then you say I have but a smattering of datatypes
    when you don't even know what your saying...

    Go on and explain,
    or you are no programmer.

    Now the topic of this post is about good tutorials,
    and they are, so follow the link at the top.
     
    Amkcoder, Sep 23, 2008
    #8
  9. Amkcoder

    Amkcoder Guest

    On Sep 23, 8:33 am, wrote:
    > On Sep 23, 6:09 pm, "Bartc" <> wrote:
    >
    > <snip>
    >
    > > I neither know nor care whether a pointer is a value, variable, type or
    > > object. But that hasn't stopped me using them quite effectively.

    >
    > I doubt you've used pointers effectively.
    >
    > Message-ID: <Xzryk.56633$>
    > Bartc said:
    >
    > > vippstar said:
    > >> Given that p is char [4][2], you should immediately be able to tell
    > >> which type *p is, p[0][0], &p[0].
    > >> (answer: char [2], char, char (*)[2])

    >
    > > I wouldn't frighten off the OP with this stuff. I don't understand half of
    > > it either.

    >
    > Now, if you don't understand types, and those who are so trivial, I
    > doubt you can use pointers effectively.
    > Even if you can, it was by luck. You certainly *can't* write a
    > tutorial about using pointers effectively, or pointers in general.


    Why don't you explain why I am wrong then, MR.PROGRAMMER,
    and just to tell you my understanding of datatypes is backed
    by the intel x86 manuals applications programming section,
    chapter on data types.

    So you call Intel liars,
    You call universities who use my same definition of pointers liars,
    And then you say I have but a smattering of datatypes
    when you don't even know what your saying...

    Go on and explain,
    or you are no programmer.

    Now the topic of this post is about good tutorials,
    and they are, so follow the link at the top.
     
    Amkcoder, Sep 23, 2008
    #9
  10. Amkcoder

    Amkcoder Guest

    On Sep 23, 8:33 am, wrote:
    > On Sep 23, 6:09 pm, "Bartc" <> wrote:
    >
    > <snip>
    >
    > > I neither know nor care whether a pointer is a value, variable, type or
    > > object. But that hasn't stopped me using them quite effectively.

    >
    > I doubt you've used pointers effectively.
    >
    > Message-ID: <Xzryk.56633$>
    > Bartc said:
    >
    > > vippstar said:
    > >> Given that p is char [4][2], you should immediately be able to tell
    > >> which type *p is, p[0][0], &p[0].
    > >> (answer: char [2], char, char (*)[2])

    >
    > > I wouldn't frighten off the OP with this stuff. I don't understand half of
    > > it either.

    >
    > Now, if you don't understand types, and those who are so trivial, I
    > doubt you can use pointers effectively.
    > Even if you can, it was by luck. You certainly *can't* write a
    > tutorial about using pointers effectively, or pointers in general.


    Why don't you explain why I am wrong then, MR.PROGRAMMER,
    and just to tell you my understanding of datatypes is backed
    by the intel x86 manuals applications programming section,
    chapter on data types.

    So you call Intel liars,
    You call universities who use my same definition of pointers liars,
    And then you say I have but a smattering of datatypes
    when you don't even know what your saying...

    Go on and explain,
    or you are no programmer.

    Now the topic of this post is about good tutorials,
    and they are, so follow the link at the top.
     
    Amkcoder, Sep 23, 2008
    #10
  11. "Bartc" <> writes:
    [...]
    > I neither know nor care whether a pointer is a value, variable, type
    > or object. But that hasn't stopped me using them quite effectively.


    But it could well stop you from communicating effectively about them.

    And I think you overestimate your own ignorance. For example, given:

    int x;
    int *obj = &x;

    I think you know that obj is an object (and a variable), &x is a
    value, and int* is a type.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Sep 23, 2008
    #11
  12. Amkcoder

    Guest

    Amkcoder wrote:
    ....
    > The definition you so waywardly complain about is repeated as a common
    > definition:
    > "A pointer is a variable that points at, or refers to, another
    > variable."


    So, if we have

    char greeting[] = "Hello, World!";
    int seven = 7;

    Then according to your definition, neither greeting+6 nor &seven are
    pointers, because they are expressions, not variables. According to
    your definition, neither (void*)0 nor malloc(256) is a pointer, both
    because they aren't variables and because they don't point at
    variables.

    I consider this to be a serious defect in your definition of a
    pointer.

    ....
    > Like I said, good tutorials...
    > Please only sincere students or real programmers comment,


    I'm a real programmer. At least, they pay me to write computer
    programs. And I know, as you apparently do not, that pointers don't
    need to be variables, and they don't need to point at variables.
     
    , Sep 23, 2008
    #12
  13. Amkcoder

    Amkcoder Guest

    On Sep 23, 9:03 am, wrote:
    > Amkcoder wrote:
    >
    > ...
    >
    > > The definition you so waywardly complain about is repeated as a common
    > > definition:
    > > "A pointer is a variable that points at, or refers to, another
    > > variable."

    >
    > So, if we have
    >
    > char greeting[] = "Hello, World!";
    > int seven = 7;
    >
    > Then according to your definition, neither greeting+6 nor &seven are
    > pointers, because they are expressions, not variables. According to
    > your definition, neither (void*)0 nor malloc(256) is a pointer, both
    > because they aren't variables and because they don't point at
    > variables.
    >
    > I consider this to be a serious defect in your definition of a
    > pointer.
    >
    > ...
    >
    > > Like I said, good tutorials...
    > > Please only sincere students or real programmers comment,

    >
    > I'm a real programmer. At least, they pay me to write computer
    > programs. And I know, as you apparently do not, that pointers don't
    > need to be variables, and they don't need to point at variables.


    Sorry,
    but a short int is exactly two bytes, and in order to use them they
    must be treated as a
    word.
    You think I don't know that you can refer a pointer to allocated
    memory,
    it is in my tutorial.

    When you declare a short int the compiler allocates two bytes for it
    (a word),
    and associates that address to the variable name.
    This can be done manually with a call to malloc, which will return the
    address
    to the first byte to your allocated space.

    To prove you wrong I will show you the following:
    short int *sint=malloc(2);
    unsigned char *a=(unsigned char *)sint;
    *a=154;
    *(a+1)=2;
    printf("%d",*sint);

    Check out the value it prints out...

    They must pay you minimum wage just to crank out code.
    I am a real programmer, 14 years in the making.
     
    Amkcoder, Sep 23, 2008
    #13
  14. Amkcoder

    Amkcoder Guest

    On Sep 23, 9:03 am, wrote:
    > Amkcoder wrote:
    >
    > ...
    >
    > > The definition you so waywardly complain about is repeated as a common
    > > definition:
    > > "A pointer is a variable that points at, or refers to, another
    > > variable."

    >
    > So, if we have
    >
    > char greeting[] = "Hello, World!";
    > int seven = 7;
    >
    > Then according to your definition, neither greeting+6 nor &seven are
    > pointers, because they are expressions, not variables. According to
    > your definition, neither (void*)0 nor malloc(256) is a pointer, both
    > because they aren't variables and because they don't point at
    > variables.
    >
    > I consider this to be a serious defect in your definition of a
    > pointer.
    >
    > ...
    >
    > > Like I said, good tutorials...
    > > Please only sincere students or real programmers comment,

    >
    > I'm a real programmer. At least, they pay me to write computer
    > programs. And I know, as you apparently do not, that pointers don't
    > need to be variables, and they don't need to point at variables.


    Sorry,
    but a short int is exactly two bytes, and in order to use them they
    must be treated as a
    word.
    You think I don't know that you can refer a pointer to allocated
    memory,
    it is in my tutorial.

    When you declare a short int the compiler allocates two bytes for it
    (a word),
    and associates that address to the variable name.
    This can be done manually with a call to malloc, which will return the
    address
    to the first byte to your allocated space.

    To prove you wrong I will show you the following:
    short int *sint=malloc(2);
    unsigned char *a=(unsigned char *)sint;
    *a=154;
    *(a+1)=2;
    printf("%d",*sint);

    Check out the value it prints out...

    They must pay you minimum wage just to crank out code.
    I am a real programmer, 14 years in the making.
     
    Amkcoder, Sep 23, 2008
    #14
  15. Amkcoder

    Amkcoder Guest

    On Sep 23, 9:03 am, wrote:
    > Amkcoder wrote:
    >
    > ...
    >
    > > The definition you so waywardly complain about is repeated as a common
    > > definition:
    > > "A pointer is a variable that points at, or refers to, another
    > > variable."

    >
    > So, if we have
    >
    > char greeting[] = "Hello, World!";
    > int seven = 7;
    >
    > Then according to your definition, neither greeting+6 nor &seven are
    > pointers, because they are expressions, not variables. According to
    > your definition, neither (void*)0 nor malloc(256) is a pointer, both
    > because they aren't variables and because they don't point at
    > variables.
    >
    > I consider this to be a serious defect in your definition of a
    > pointer.
    >
    > ...
    >
    > > Like I said, good tutorials...
    > > Please only sincere students or real programmers comment,

    >
    > I'm a real programmer. At least, they pay me to write computer
    > programs. And I know, as you apparently do not, that pointers don't
    > need to be variables, and they don't need to point at variables.


    Sorry,
    when you declare a short int it allocates two bytes and associates the
    beginning of the
    address to the two bytes to your variable.
    And I do understand that a pointer can be refered to space allocated
    by a call to malloc,
    It is in my tutorial.

    short int *sint=malloc(2);
    unsigned char *a=(unsigned char *)sint;
    *a=154;
    *(a+1)=2;
    printf("%d",*sint);

    Check out the value it prints out.
    They must pay you minimum wage just to crank out code.
    I am a real programmer, 14 years in the making.
     
    Amkcoder, Sep 23, 2008
    #15
  16. Amkcoder

    Amkcoder Guest

    On Sep 23, 9:34 am, Richard Heathfield <> wrote:
    > Amkcoder said:
    >
    >
    >
    > > On Sep 23, 9:03 am, wrote:
    > >> Amkcoder wrote:

    >
    > >> ...

    >
    > >> > The definition you so waywardly complain about is repeated as a common
    > >> > definition:
    > >> > "A pointer is a variable that points at, or refers to, another
    > >> > variable."

    >
    > >> So, if we have

    >
    > >> char greeting[] = "Hello, World!";
    > >> int seven = 7;

    >
    > >> Then according to your definition, neither greeting+6 nor &seven are
    > >> pointers, because they are expressions, not variables. According to
    > >> your definition, neither (void*)0 nor malloc(256) is a pointer, both
    > >> because they aren't variables and because they don't point at
    > >> variables.

    >
    > >> I consider this to be a serious defect in your definition of a
    > >> pointer.

    >
    > >> ...

    >
    > >> > Like I said, good tutorials...
    > >> > Please only sincere students or real programmers comment,

    >
    > >> I'm a real programmer. At least, they pay me to write computer
    > >> programs. And I know, as you apparently do not, that pointers don't
    > >> need to be variables, and they don't need to point at variables.

    >
    > > Sorry,
    > > but a short int is exactly two bytes,

    >
    > No, a short int is at least 16 bits, and at least one byte, in width, but
    > there is no upper limit.
    >
    > > and in order to use them they
    > > must be treated as a
    > > word.

    >
    > No, they must be treated as short ints (modulo object representation
    > techniques which don't seem to be relevant here).
    >
    > > You think I don't know that you can refer a pointer to allocated
    > > memory,
    > > it is in my tutorial.

    >
    > He's not saying you don't know that. He's saying your definition of a
    > pointer fails to take it into account.
    >
    > > When you declare a short int the compiler allocates two bytes for it

    >
    > No, when you *define* a short int, the implementation allocates
    > sizeof(short int) bytes for it. This may be 2, but may only be 1 (on
    > systems with chars at least 16 bits wide), or could be 3 or 4 or 42 or
    > whatever. 2 is common, it's true. I've seen 1, and I've heard of 8.
    >
    > > To prove you wrong I will show you the following:
    > > short int *sint=malloc(2);
    > > unsigned char *a=(unsigned char *)sint;
    > > *a=154;
    > > *(a+1)=2;
    > > printf("%d",*sint);

    >
    > > Check out the value it prints out...

    >
    > You appear to think that the behaviour you observe on your system
    > represents fundamental truths about C. It doesn't.
    >
    > > They must pay you minimum wage just to crank out code.
    > > I am a real programmer, 14 years in the making.

    >
    > How nice. But you would do well to listen to James. He's what they call an
    > "expert".
    >
    > --
    > Richard Heathfield <http://www.cpax.org.uk>
    > Email: -http://www. +rjh@
    > Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    > "Usenet is a strange place" - dmr 29 July 1999


    The reason Universities, who make real programmers, say that a pointer
    is a variable
    that holds the address of another, it is.
    This is because every time you declare a pointer it allocates enough
    bytes to hold
    a value, which will be treated as an address, and this space has its
    own address just like a
    variable.
    The only difference is for each pointer declared, it is usually the
    same amount
    of bytes allocated to hold the address. The type of the pointer merely
    indicates how the compiler should treat the data pointed by the
    address
    stored in the pointer when it is dereferenced.
    The compiler knows to do this because it knows you declared a pointer
    and not
    a ordinary variable.
    So he's is an expert?
    Then call me the professional.
     
    Amkcoder, Sep 23, 2008
    #16
  17. Amkcoder

    Amkcoder Guest

    On Sep 23, 9:34 am, Richard Heathfield <> wrote:
    > Amkcoder said:
    >
    >
    >
    > > On Sep 23, 9:03 am, wrote:
    > >> Amkcoder wrote:

    >
    > >> ...

    >
    > >> > The definition you so waywardly complain about is repeated as a common
    > >> > definition:
    > >> > "A pointer is a variable that points at, or refers to, another
    > >> > variable."

    >
    > >> So, if we have

    >
    > >> char greeting[] = "Hello, World!";
    > >> int seven = 7;

    >
    > >> Then according to your definition, neither greeting+6 nor &seven are
    > >> pointers, because they are expressions, not variables. According to
    > >> your definition, neither (void*)0 nor malloc(256) is a pointer, both
    > >> because they aren't variables and because they don't point at
    > >> variables.

    >
    > >> I consider this to be a serious defect in your definition of a
    > >> pointer.

    >
    > >> ...

    >
    > >> > Like I said, good tutorials...
    > >> > Please only sincere students or real programmers comment,

    >
    > >> I'm a real programmer. At least, they pay me to write computer
    > >> programs. And I know, as you apparently do not, that pointers don't
    > >> need to be variables, and they don't need to point at variables.

    >
    > > Sorry,
    > > but a short int is exactly two bytes,

    >
    > No, a short int is at least 16 bits, and at least one byte, in width, but
    > there is no upper limit.
    >
    > > and in order to use them they
    > > must be treated as a
    > > word.

    >
    > No, they must be treated as short ints (modulo object representation
    > techniques which don't seem to be relevant here).
    >
    > > You think I don't know that you can refer a pointer to allocated
    > > memory,
    > > it is in my tutorial.

    >
    > He's not saying you don't know that. He's saying your definition of a
    > pointer fails to take it into account.
    >
    > > When you declare a short int the compiler allocates two bytes for it

    >
    > No, when you *define* a short int, the implementation allocates
    > sizeof(short int) bytes for it. This may be 2, but may only be 1 (on
    > systems with chars at least 16 bits wide), or could be 3 or 4 or 42 or
    > whatever. 2 is common, it's true. I've seen 1, and I've heard of 8.
    >
    > > To prove you wrong I will show you the following:
    > > short int *sint=malloc(2);
    > > unsigned char *a=(unsigned char *)sint;
    > > *a=154;
    > > *(a+1)=2;
    > > printf("%d",*sint);

    >
    > > Check out the value it prints out...

    >
    > You appear to think that the behaviour you observe on your system
    > represents fundamental truths about C. It doesn't.
    >
    > > They must pay you minimum wage just to crank out code.
    > > I am a real programmer, 14 years in the making.

    >
    > How nice. But you would do well to listen to James. He's what they call an
    > "expert".
    >
    > --
    > Richard Heathfield <http://www.cpax.org.uk>
    > Email: -http://www. +rjh@
    > Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    > "Usenet is a strange place" - dmr 29 July 1999


    The reason universities, who make real programmers, use the definition
    that a pointer
    is a variable that holds the address to another variable in memory, is
    because
    it is.
    Every time you declare a pointer space is allocated for it to hold a
    value,
    which will be treated as an address. This space has its own address,
    just like a variable.
    So that every time a pointer is declared the same amount of space is
    allocated
    capable of holding an address. The pointer's type merely indicates how
    to treat the data it refers to when it is dereferenced.
    So he is an expert,
    then call me the professional.
     
    Amkcoder, Sep 23, 2008
    #17
  18. On Tue, 23 Sep 2008 09:50:21 -0700, Amkcoder wrote:


    > The reason universities, who make real programmers, use the definition
    > that a pointer


    I am not qualified to discuss this topic, but will point out that your
    posts seem to be posted 2 or 3 times each.

    sf
     
    jellybean stonerfish, Sep 23, 2008
    #18
  19. Amkcoder

    Richard Guest

    Amkcoder <> writes:

    > On Sep 23, 9:34 am, Richard Heathfield <> wrote:
    >> Amkcoder said:
    >>
    >>
    >>
    >> > On Sep 23, 9:03 am, wrote:
    >> >> Amkcoder wrote:

    >>
    >> >> ...

    >>
    >> >> > The definition you so waywardly complain about is repeated as a common
    >> >> > definition:
    >> >> > "A pointer is a variable that points at, or refers to, another
    >> >> > variable."

    >>
    >> >> So, if we have

    >>
    >> >> char greeting[] = "Hello, World!";
    >> >> int seven = 7;

    >>
    >> >> Then according to your definition, neither greeting+6 nor &seven are
    >> >> pointers, because they are expressions, not variables. According to
    >> >> your definition, neither (void*)0 nor malloc(256) is a pointer, both
    >> >> because they aren't variables and because they don't point at
    >> >> variables.

    >>
    >> >> I consider this to be a serious defect in your definition of a
    >> >> pointer.

    >>
    >> >> ...

    >>
    >> >> > Like I said, good tutorials...
    >> >> > Please only sincere students or real programmers comment,

    >>
    >> >> I'm a real programmer. At least, they pay me to write computer
    >> >> programs. And I know, as you apparently do not, that pointers don't
    >> >> need to be variables, and they don't need to point at variables.

    >>
    >> > Sorry,
    >> > but a short int is exactly two bytes,

    >>
    >> No, a short int is at least 16 bits, and at least one byte, in width, but
    >> there is no upper limit.
    >>
    >> > and in order to use them they
    >> > must be treated as a
    >> > word.

    >>
    >> No, they must be treated as short ints (modulo object representation
    >> techniques which don't seem to be relevant here).
    >>
    >> > You think I don't know that you can refer a pointer to allocated
    >> > memory,
    >> > it is in my tutorial.

    >>
    >> He's not saying you don't know that. He's saying your definition of a
    >> pointer fails to take it into account.
    >>
    >> > When you declare a short int the compiler allocates two bytes for it

    >>
    >> No, when you *define* a short int, the implementation allocates
    >> sizeof(short int) bytes for it. This may be 2, but may only be 1 (on
    >> systems with chars at least 16 bits wide), or could be 3 or 4 or 42 or
    >> whatever. 2 is common, it's true. I've seen 1, and I've heard of 8.
    >>
    >> > To prove you wrong I will show you the following:
    >> > short int *sint=malloc(2);
    >> > unsigned char *a=(unsigned char *)sint;
    >> > *a=154;
    >> > *(a+1)=2;
    >> > printf("%d",*sint);

    >>
    >> > Check out the value it prints out...

    >>
    >> You appear to think that the behaviour you observe on your system
    >> represents fundamental truths about C. It doesn't.


    What absolute nonsense. The behaviour on a conforming system must be a
    truth or it would not be conforming.

    This constant desire to confuse people with a "pointer is not an
    address" is simply ridiculous. It is an "address". You address an object
    or memory or whatever through it. One representation of that address is
    as a value which can be displayed as a hexadecimal memory "address".

    Why, oh why try to make C into something it is not?

    The comment the other day about my "magical debugger" representing
    pointers as values or 32 bit hex strings was simply astounding. As if it
    was a bad thing.

    >>
    >> > They must pay you minimum wage just to crank out code.
    >> > I am a real programmer, 14 years in the making.

    >>
    >> How nice. But you would do well to listen to James. He's what they call an
    >> "expert".
    >>
    >> --
    >> Richard Heathfield <http://www.cpax.org.uk>
    >> Email: -http://www. +rjh@
    >> Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    >> "Usenet is a strange place" - dmr 29 July 1999

    >
    > The reason Universities, who make real programmers, say that a pointer
    > is a variable
    > that holds the address of another, it is.
    > This is because every time you declare a pointer it allocates enough
    > bytes to hold
    > a value, which will be treated as an address, and this space has its
    > own address just like a
    > variable.
    > The only difference is for each pointer declared, it is usually the
    > same amount
    > of bytes allocated to hold the address. The type of the pointer merely
    > indicates how the compiler should treat the data pointed by the
    > address
    > stored in the pointer when it is dereferenced.
    > The compiler knows to do this because it knows you declared a pointer
    > and not
    > a ordinary variable.
    > So he's is an expert?
    > Then call me the professional.


    --
     
    Richard, Sep 23, 2008
    #19
  20. Amkcoder

    Guest

    Amkcoder wrote:
    > On Sep 23, 9:03 am, wrote:

    ....
    > > programs. And I know, as you apparently do not, that pointers don't
    > > need to be variables, and they don't need to point at variables.

    >
    > Sorry,
    > but a short int is exactly two bytes,


    On many machines that's true; though the standard imposes no such
    requirement. There are machines where CHAR_BITS==16, and short is a
    one-byte type. There are other machines where char is 8 bits, long
    long is 64 bits, and all of the types between char and long long are
    32 bits.

    > ... and in order to use them they
    > must be treated as a
    > word.


    On many machines that's true. On other machines they can be one word
    long, or a fraction of a word. The standard imposes no requirements on
    that kind of thing.

    > You think I don't know that you can refer a pointer to allocated
    > memory,
    > it is in my tutorial.


    Then you should revise your definition of a pointer to allow for that
    possibility.

    > When you declare a short int the compiler allocates two bytes for it
    > (a word),
    > and associates that address to the variable name.
    > This can be done manually with a call to malloc, which will return the
    > address
    > to the first byte to your allocated space.


    Yes, which need not be the address of a variable.

    > To prove you wrong I will show you the following:
    > short int *sint=malloc(2);
    > unsigned char *a=(unsigned char *)sint;
    > *a=154;
    > *(a+1)=2;
    > printf("%d",*sint);
    >
    > Check out the value it prints out...


    There are two different common values that code could print out, and
    real machines where it will print 154 because unsigned char and short
    int are both 16 bits long, and real machines where it will print
    garbage, or possibly simply abort, because all integer types between
    (but not including) 'char' and 'long long' are 4 bytes long.

    None of which proves that the value of sint points at a variable. Your
    point is?

    > They must pay you minimum wage just to crank out code.


    I'm no longer allowed to use the tax tables when computing my federal
    taxes; they don't go high enough. In my profession, that doesn't
    indicate an unusually high salary. In fact, my salary is below the
    level you might expect from my education and experience levels,
    because non-military scientific computer programming doesn't tend to
    pay as well as military or commercial programming.

    > I am a real programmer, 14 years in the making.


    I've got 34 years of experience, myself.
     
    , Sep 23, 2008
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Chaos Master

    Good books/tutorials on VHDL?

    Chaos Master, Feb 18, 2004, in forum: VHDL
    Replies:
    1
    Views:
    605
  2. Eric DELAGE
    Replies:
    2
    Views:
    733
  3. sd
    Replies:
    4
    Views:
    3,073
  4. Thomas S.
    Replies:
    0
    Views:
    605
    Thomas S.
    Nov 12, 2004
  5. Collin VanDyck

    Good Tutorials?

    Collin VanDyck, Dec 8, 2004, in forum: Java
    Replies:
    1
    Views:
    381
Loading...

Share This Page