"Mastering C Pointers"....

Discussion in 'C Programming' started by maniac, Nov 1, 2003.

  1. maniac

    maniac Guest

    Hey guys, I'm new here, just a simple question.

    I'm learning to Program in C, and I was recommended a book called,
    "Mastering C Pointers", just asking if any of you have read it,
    and if it's worth the $25USD.

    I'm just looking for a book on Pointers, because from what I've
    read it's one of the toughest topics to understand.

    thanks in advanced.

    sincerely ... Andy
     
    maniac, Nov 1, 2003
    #1
    1. Advertising

  2. On Sat, 01 Nov 2003 12:51:44 -0500, maniac wrote:

    > Hey guys, I'm new here, just a simple question.
    >
    > I'm learning to Program in C, and I was recommended a book called,
    > "Mastering C Pointers", just asking if any of you have read it,
    > and if it's worth the $25USD.
    >
    > I'm just looking for a book on Pointers, because from what I've
    > read it's one of the toughest topics to understand.
    >
    > thanks in advanced.


    Personally I find it hard to believe that anyone needs to
    spend $25 on a book that only covers pointers, but that's just
    me.

    My suggestion would be for you to start out with a good general
    purpose C book, like K&R, and then worry about other books only
    when you actually have problems.

    In fact, since you've already found this newsgroup, you can come
    here with your problems (C problems, that is) first.

    -Sheldon

    Just before I hit send I decided I'd better search Amazon. I
    found the following quote about this book:

    "the writer uses turbo c and MS DOS;
    it's kind of an old-school book"

    That means you shouldn't use the book.
     
    Sheldon Simms, Nov 1, 2003
    #2
    1. Advertising

  3. maniac

    Andy Guest

    -Sheldon
    >
    > Just before I hit send I decided I'd better search Amazon. I
    > found the following quote about this book:
    >
    > "the writer uses turbo c and MS DOS;
    > it's kind of an old-school book"
    >
    > That means you shouldn't use the book.


    thanks, I just wanted some advice, thats all.
    I appreciate your help.
     
    Andy, Nov 1, 2003
    #3
  4. maniac

    Roose Guest

    Try "Pointers on C", that's not a bad book, and covers pointers fairly well.
    It has a lot of basic C stuff too.


    "Andy" <> wrote in message
    news:YKSob.10682$...
    > -Sheldon
    > >
    > > Just before I hit send I decided I'd better search Amazon. I
    > > found the following quote about this book:
    > >
    > > "the writer uses turbo c and MS DOS;
    > > it's kind of an old-school book"
    > >
    > > That means you shouldn't use the book.

    >
    > thanks, I just wanted some advice, thats all.
    > I appreciate your help.
    >
     
    Roose, Nov 1, 2003
    #4
  5. maniac

    Michael Str. Guest

    maniac <> wrote in message news:<9oSob.5012$>...
    > Hey guys, I'm new here, just a simple question.
    >
    > I'm learning to Program in C, and I was recommended a book called,
    > "Mastering C Pointers", just asking if any of you have read it,
    > and if it's worth the $25USD.
    >
    > I'm just looking for a book on Pointers, because from what I've
    > read it's one of the toughest topics to understand.
    >
    > thanks in advanced.
    >
    > sincerely ... Andy


    Hi Andy !

    How many beer can you buy for $25USD ?

    Try this link:
    http://home.netcom.com/~tjensen/ptr/pointers.htm

    I guess you can find many good links related to this issue.

    regards
    Michael
     
    Michael Str., Nov 1, 2003
    #5
  6. maniac

    Larry Niven Guest

    I would rather read a book than reading on the Web, because I have poor eyesight.

    Your eyes are more precious than $25USD, so I suggest you buy the book.

    In fact, that book is worth reading.
     
    Larry Niven, Nov 2, 2003
    #6
  7. On Sat, 01 Nov 2003 21:12:00 -0800, Larry Niven wrote:

    > I would rather read a book than reading on the Web, because I have poor eyesight.
    > Your eyes are more precious than $25USD, so I suggest you buy the book.
    > In fact, that book is worth reading.


    Apparently you have read the book. Tell me, do the words "far pointer"
    and "near pointer" appear in the book? If so, don't read the book.
     
    Sheldon Simms, Nov 2, 2003
    #7
  8. maniac wrote:

    > Hey guys, I'm new here, just a simple question.
    >
    > I'm learning to Program in C, and I was recommended a book called,
    > "Mastering C Pointers", just asking if any of you have read it,
    > and if it's worth the $25USD.


    I am given to understand that the book is firmly rooted in MS-DOS, which
    makes it unsuitable for /general/ understanding about pointers.

    > I'm just looking for a book on Pointers, because from what I've
    > read it's one of the toughest topics to understand.


    Actually, pointers aren't really that hard to understand.

    Every object is located somewhere, right? Well, when we refer to that
    location, we "point" to the object.

    In common parlance, the object's location is called an "address". An object
    that stores an address is called a "pointer object". A value that is an
    address is called a "pointer value". We can assign pointer values to
    pointer objects.

    There is a special pointer value called the null pointer value which is
    guaranteed not to point to any object.

    To "get at" the value stored at the address pointed to by a pointer, you
    "dereference" the pointer. Thus:

    int i = 6; /* i is an object with type int and the value 6 */
    int j = 42; /* j is an object with type int and the value 42 */
    int *p = &i; /* p is an object with type pointer-to-int and the value &i */

    printf("i = %d\n", *p); /* deference p; prints 6 */
    p = j; /* now p points at the j object */
    printf("i = %d\n", *p); /* this time, it prints 42 */

    It is also possible to point at functions. When you dereference a function
    pointer, you actually call the function pointed to:

    double (*fp)(double) = sin;

    double d = (*fp)(180.0 / 3.14); /* d gets the value 0.0 */
    fp = cos;
    d = (*fp)(180.0 / 3.14); /* this time, d gets the value -1.0 */


    When you do arithmetic with pointers, it is done in terms of the objects to
    which they point. So if, say, you have an array of ints (and, as you may be
    aware, ints normally are a tad bigger than a single byte):

    int myarray[6] = { 0, 1, 2, 3, 4, 5 };

    int *p = myarray; /* p points to first int in myarray array */
    ++p; /* p now points to /second/ int in myarray array, NOT the second byte
    in the first int! */


    One last point: it's not generally possible to know whether a pointer value
    is valid or not unless its value is NULL, in which case you know for sure
    that it's invalid. This is useful information.


    That's it. Pointers are really that simple. If you're still having trouble
    with pointers, ask a more specific question.


    --
    Richard Heathfield :
    "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
    C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
    K&R answers, C books, etc: http://users.powernet.co.uk/eton
     
    Richard Heathfield, Nov 2, 2003
    #8
  9. maniac

    Andy Guest


    > That's it. Pointers are really that simple. If you're still having trouble
    > with pointers, ask a more specific question.



    well it sounds simple enough, but I've heard so many things about pointers
    that I thought it will be a good idea to get a book just about pointers
    but I guess C books have pointer references in them as well.

    but I'll take your advice and ask here if I have more questions.

    thanx.
     
    Andy, Nov 2, 2003
    #9
  10. maniac

    CBFalconer Guest

    Richard Heathfield wrote:
    >

    .... snip ...
    >
    > One last point: it's not generally possible to know whether a
    > pointer value is valid or not unless its value is NULL, in which
    > case you know for sure that it's invalid. This is useful
    > information.


    GNit: unless you know the pointers ancestry, i.e. how its value
    was set. If it was never set you can be fairly sure it is
    invalid.

    --
    Chuck F () ()
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!
     
    CBFalconer, Nov 2, 2003
    #10
  11. CBFalconer wrote:

    > Richard Heathfield wrote:
    >>

    > ... snip ...
    >>
    >> One last point: it's not generally possible to know whether a
    >> pointer value is valid or not unless its value is NULL, in which
    >> case you know for sure that it's invalid. This is useful
    >> information.

    >
    > GNit: unless you know the pointers ancestry, i.e. how its value
    > was set. If it was never set you can be fairly sure it is
    > invalid.


    Oh, absolutely right. And there are circumstances in which it can /become/
    invalid even if you did set it. But I think the OP can cross those bridges
    (with this newsgroup's help) when he comes to them.

    --
    Richard Heathfield :
    "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
    C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
    K&R answers, C books, etc: http://users.powernet.co.uk/eton
     
    Richard Heathfield, Nov 2, 2003
    #11
  12. Richard Heathfield wrote:

    > Actually, pointers aren't really that hard to understand.
    >

    <snip>
    >
    > printf("i = %d\n", *p); /* deference p; prints 6 */
    > p = j; /* now p points at the j object */


    If pointers are so easy, why did I make this mistake? It should, of course,
    be:

    p = &j;

    Thanks to "those who know me have no need of my name" for pointing this out.

    --
    Richard Heathfield :
    "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
    C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
    K&R answers, C books, etc: http://users.powernet.co.uk/eton
     
    Richard Heathfield, Nov 2, 2003
    #12
  13. maniac

    Alan Connor Guest

    On Sun, 2 Nov 2003 06:22:40 +0000 (UTC), Richard Heathfield <> wrote:
    >
    >
    > maniac wrote:
    >
    >> Hey guys, I'm new here, just a simple question.
    >>
    >> I'm learning to Program in C, and I was recommended a book called,
    >> "Mastering C Pointers", just asking if any of you have read it,
    >> and if it's worth the $25USD.

    >
    > I am given to understand that the book is firmly rooted in MS-DOS, which
    > makes it unsuitable for /general/ understanding about pointers.
    >
    >> I'm just looking for a book on Pointers, because from what I've
    >> read it's one of the toughest topics to understand.

    >
    > Actually, pointers aren't really that hard to understand.
    >
    > Every object is located somewhere, right? Well, when we refer to that
    > location, we "point" to the object.
    >


    Richard,

    Would you mind defining "object" for a shell scripter just starting to
    learn C?

    (I've saved this pointer article. Thanks.)

    --
    Alan C this post ends with w
    q
     
    Alan Connor, Nov 2, 2003
    #13
  14. maniac

    Malcolm Guest

    "Alan Connor" <> wrote in message
    >
    > Would you mind defining "object" for a shell scripter just starting to
    > learn C?
    >

    The problem is that "object" has one meaning in object-oriented programming,
    and a related but different menaing in C.

    In C an "object" is something that a variable, either a basic type like an
    int or a float, or a compound type like a structure, can hold. Because C
    allows direct access to memory, an "object" is just an area of memory that
    is interpreted in a certain way.

    In object-oriented programming, an "object" is a data type that represents
    something in the world the program is trying to simulate, and which has
    relationships with other objects. For instance, you might have
    "streetlights", "torches", "headlights" and "traffic lights" as light
    objects in your program, and all might be related because all have an
    intensity, a colour, and a location.

    Underneath the bonnet, object-oriented "objects" are of course stored as
    patterns of bits in memory, but many object-oriented languages don't allow
    or discourage accessing this memory directly.
     
    Malcolm, Nov 2, 2003
    #14
  15. maniac

    Roose Guest

    In C, there is no technical term "object", but he means anything which
    occupies memory can be pointed at. Any code (a function, individual CPU
    instructions) or data (a simple int, char; an array; a struct or union; a
    block of malloc'd memory) can be pointed at.

    I remember learning C, and being confused by the syntax of the language. If
    they had just put it in terms of simple arithmetic (which is ALL it is,
    really), then I would have been able to grasp it quicker. Unfortunately I
    haven't seen a lot of books that do this, because it requires some basic
    hardware knowledge (which is pretty trivial). Most books are biased toward
    the abstract, since that is what standard C is -- an abstraction of
    hardware. BUT it will help a lot to ALSO come at it from the concrete side,
    i.e. see what is going on in the memory of your computer. To learn anything
    you need to have more than one representation of it in your head; otherwise
    you're just memorizing facts and words.

    I would suggest learning to read hex (e.g. what decimal value is 0x00010000)
    if you don't, and copy some C functions which use:

    - pointers of different types (pointer to int, char; pointer to struct;
    pointer to array, etc)
    - the & operator
    - the ++ -- += -= operators on pointers (as opposed to pn integers)
    - the * operator

    Compile and run them. Get a good debugger (Codewarrior, MSVC++ work fine),
    and open up the stack window. Also helpful is a debugger which can view
    memory as an array of hex numbers. View the stack as memory as well. See
    how the variables are laid out consecutively on the stack. See that a
    pointer is an integer at the hardware level. Step through _each line_ of
    code and _very carefully_ note what happens to each variable. Take note of
    how they are incremented/decremented. See how pointers to variables on the
    stack have numeric values that are the addresses in your debugger's memory
    viewer.

    Then if the code uses the [] or -> operators, rewrite these in terms of the
    previous operators, and then you will really understand what they do.
    Change loops that use [] to use pointers.

    This exercise will also help when you inevitably make some mistake with
    pointers. If you only think about the abstract C language, then when you
    start to program you will be utterly confused and frustrated when you
    overrun a buffer and start reading garbage values, or when you cause a
    machine exception by dereferencing a bad pointer. In shell scripting for
    example, you don't really run into variables with garbage values, and it
    will help to understand why.

    When you understand this concrete stuff, the abstract will become clearer as
    well. You'll understand why the C language was designed as it is. It seems
    like a weird language at first, but you will see that it is a very thin
    layer on of hardware.

    > Would you mind defining "object" for a shell scripter just starting to
    > learn C?
    >
    > (I've saved this pointer article. Thanks.)
    >
    > --
    > Alan C this post ends with w
    > q
     
    Roose, Nov 2, 2003
    #15
  16. Alan Connor <> wrote:

    > Would you mind defining "object" for a shell scripter just starting to
    > learn C?


    Generally, in C an object is something that can hold a value.

    The C Standard states:

    ISO/IEC 9899:TC1
    3.14 object
    region of data storage in the execution environment, the contents of
    which can represent values.
    NOTE: When referenced, an object may be interpreted as having a
    particular type; see 6.3.2.1.

    6.3.2.1 Lvalues, arrays, and function designators
    An lvalue is an expression with an object type or an incomplete type
    other than void; [...] When an object is said to have a particular
    type, the type is specified by the lvalue used to designate the object.
    [...]

    The C Rationale explains:
    The definition of object does not employ the notion of type. Thus an
    object has no type in and of itself. However, since an object may only
    be designated by an lvalue (see 6.3.2.1), the phrase "the type of an
    object" is taken to mean, here and in the Standard, "the type of the
    lvalue designating this object", and "the value of an object" means
    "the contents of the object interpreted as a value of the type of the
    lvalue designating the object".

    <phew> Confused?
    Let's have a look at a simple example:

    int i = 42;

    With this definition we create an object of size sizeof(int) that
    resides somewhere in memory. The only way to access this object is
    via the 'name' we gave it: i. Since i has type int and we provided
    an initial value of 42 we now can say:

    i is an lvalue designating an object of type int that contains the
    value 42.

    or, less correct, but much more convenient:

    i is an {object of type} int with value 42.


    Another one:

    char *cp = NULL;

    cp is an lvalue designating an object of type pointer-to-character
    that contains the value NULL.

    or just:

    cp is an {object of type} pointer-to-character with value NULL.


    HTH a bit
    Regards
    --
    Irrwahn
    ()
     
    Irrwahn Grausewitz, Nov 2, 2003
    #16
  17. Alan Connor wrote:

    > Richard,
    >
    > Would you mind defining "object" for a shell scripter just starting to
    > learn C?


    Sure. It's a region of storage.

    Here are some trivial examples:

    int i = 6; /* i is an object. It has type int, and the value 6 */

    double d = 3.14; /* d is an object, of type double and value 3.14 */

    struct foo { int n; double r; } myfoo = { 42, 1.618 }; /* myfoo is an object
    of type struct foo, with a value that I choose to express as { 42, 1.618 }
    */

    Less trivial examples exist, as I'm sure you really didn't want to know.

    >
    > (I've saved this pointer article. Thanks.)


    Please apply the correction, too. :)

    In case you missed it, p = j; should be p = &j;

    --
    Richard Heathfield :
    "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
    C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
    K&R answers, C books, etc: http://users.powernet.co.uk/eton
     
    Richard Heathfield, Nov 2, 2003
    #17
  18. Roose wrote:

    > In C, there is no technical term "object",


    Wrong. The C99 standard defines "object" as "region of data storage in the
    execution environment, the contents of which can represent values". The
    earlier standard defines the same term in the same way.

    It's hard - very hard - to read the language definition for any length of
    time without coming across the term.


    > but he means anything which
    > occupies memory can be pointed at.


    Wrong. That's not what I meant. I meant what I said.

    > Any code (a function, individual CPU
    > instructions) or data (a simple int, char; an array; a struct or union; a
    > block of malloc'd memory) can be pointed at.


    No, there is no well-defined way, in C, to point at individual CPU
    instructions. Furthermore, functions (which /can/ be pointed at) are not
    objects.

    <snip>

    You offered some highly implementation-specific advice which may well
    confuse rather than elucidate. I've removed it from this reply as a service
    to the reader.

    --
    Richard Heathfield :
    "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
    C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
    K&R answers, C books, etc: http://users.powernet.co.uk/eton
     
    Richard Heathfield, Nov 2, 2003
    #18
  19. maniac

    Roose Guest

    I know you still hold a grudge for being so thoroughly embarassed, but give
    it a rest. You already know my position. I am concerned with the real
    world. I am trying to help the guy out in a useful and simple way, and not
    confuse him with irrelevant details. FIRST you learn how to write a program
    that RUNS and does what you want, then you learn how to write portable C and
    the C standard (if ever). Writing portable C takes considerably more time,
    at least for the beginner.

    Fine I was wrong about the term object. Having worked as a professional C
    programmer for many years, I have never heard anyone refer to an "object" in
    C in this technical sense. That tells you how useful this term is. Also
    it's common for programmers to program in both C and C++, so using the term
    object in C is confusing. It's not an important word at all in C, but very
    important in C++.

    > You offered some highly implementation-specific advice which may well
    > confuse rather than elucidate. I've removed it from this reply as a

    service
    > to the reader.


    I think your advice was fine, worth reading. But as I noted in my post, you
    need to learn something from at least two perspectives to _really_ learn it.
    Approaching it from the abstract only is not sufficient. You have to learn
    _specifics_ and then generalize. As a person with some teaching experience
    as a TA, I can say this for a fact. People, in general, are not good at
    grasping generalizations and abstractions. They need to have something
    concrete to feel out first.

    Could you learn what a ring is without learning how to use integers and
    matrices? Etc. It doesn't mean anything without specifics.

    I'm trying to help the guy learn. You're trying to beat off to your
    knowledge about the C standard.

    (Also, if you mention the quoting again, I'm going to force you into
    childish, desperate wordplay again...)
     
    Roose, Nov 2, 2003
    #19
  20. Roose wrote:

    [snip]

    Can you just please stop being so defensive? There is nothing
    wrong with being wrong. A simple thank you when you are being
    corrected gives more credo than having to be dragged kicked and
    screaming out of ignorance.

    The grudge seems to be on your side FWIW.

    --
    Thomas.
     
    Thomas Stegen, Nov 2, 2003
    #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.

Share This Page