Re: RIP Dennis Ritchie

Discussion in 'C++' started by Lynn McGuire, Oct 13, 2011.

  1. Lynn McGuire

    Lynn McGuire Guest

    On 10/13/2011 9:38 AM, Leigh Johnston wrote:
    > Father Of C And UNIX, Dennis Ritchie, Passes Away At Age 70.


    I always thought that "The C Programming Language"
    book was one of the best programming books that I
    read. Very clear and concise.

    Lynn
     
    Lynn McGuire, Oct 13, 2011
    #1
    1. Advertising

  2. 13.10.2011 22:22, Lynn McGuire kirjoitti:
    > On 10/13/2011 9:38 AM, Leigh Johnston wrote:
    >> Father Of C And UNIX, Dennis Ritchie, Passes Away At Age 70.

    >
    > I always thought that "The C Programming Language"
    > book was one of the best programming books that I
    > read. Very clear and concise.
    >
    > Lynn
    >


    Indeed. I did not understand anything about Pascal, until I read the
    "The C Programming Language". It opened my eyes to how computers work.

    The pointers in Pascal was a mystery for me.
     
    Donkey Hottie, Oct 13, 2011
    #2
    1. Advertising

  3. Lynn McGuire

    red floyd Guest

    On 10/13/2011 12:53 PM, Donkey Hottie wrote:
    > 13.10.2011 22:22, Lynn McGuire kirjoitti:
    >> On 10/13/2011 9:38 AM, Leigh Johnston wrote:
    >>> Father Of C And UNIX, Dennis Ritchie, Passes Away At Age 70.

    >>
    >> I always thought that "The C Programming Language"
    >> book was one of the best programming books that I
    >> read. Very clear and concise.
    >>
    >> Lynn
    >>

    >
    > Indeed. I did not understand anything about Pascal, until I read the
    > "The C Programming Language". It opened my eyes to how computers work.
    >
    > The pointers in Pascal was a mystery for me.


    Find a copy of Cooper and Clancy's "Oh Pascal!" Best explanation of
    pointers I ever read.
     
    red floyd, Oct 14, 2011
    #3
  4. Lynn McGuire

    Szyk Guest


    >> The pointers in Pascal was a mystery for me.

    >
    > Find a copy of Cooper and Clancy's "Oh Pascal!" Best explanation of
    > pointers I ever read.


    The best explanation for pointers:
    >>>Pointers are memory adresses.<<<

    No less no more, no bs. Just asm experience...
     
    Szyk, Oct 14, 2011
    #4
  5. Szyk <> wrote:

    > >> The pointers in Pascal was a mystery for me.

    > >
    > > Find a copy of Cooper and Clancy's "Oh Pascal!" Best explanation of
    > > pointers I ever read.


    > The best explanation for pointers:
    > >>>Pointers are memory adresses.<<<

    > No less no more, no bs. Just asm experience...


    There's more to pointers than just being memory addresses -
    a pointer also comes with a type that controls how it is de-
    referenced or what happens when an (integer) number is added
    to it. If a pointer would be identical to an assembler memory
    address each dereference would (as it is in assembler) require
    specifying how many bytes at that address must be fetched.
    And when you add a number to a memory address in assembler
    the result is the direct sum of that number and the address,
    while for a pointer it's the original value plus the product
    of the number and the size of the type of what the pointer
    points to.

    Thus pointers are a higher-level constructs and not just mere
    memory addresses. There would be no need for pointer casts in
    C++ (or C) if pointers would be just memory addresses.

    Regards, Jens
    --
    \ Jens Thoms Toerring ___
    \__________________________ http://toerring.de
     
    Jens Thoms Toerring, Oct 14, 2011
    #5
  6. Lynn McGuire

    Stefan Ram Guest

    pointers (was: RIP Dennis Ritchie)

    (Jens Thoms Toerring) writes:
    >And when you add a number to a memory address in assembler
    >the result is the direct sum of that number and the address,
    >while for a pointer it's the original value plus the product
    >of the number and the size of the type of what the pointer
    >points to.


    I do not believe that this applies to functions pointers.

    It might apply to object pointers. While one cannot say that
    object pointers are memory addresses, one might say that
    they are array addresses: p+1 points to the next object in
    an array of objects of the type of *p.

    It should not only add the size to the memory address, but
    also take care of alignment requirements.

    However, some programs use only pointers, but do not use
    pointer arithmetics. To understand such programs, it might
    help to think of the pointers as being memory addresses.
     
    Stefan Ram, Oct 15, 2011
    #6
  7. Re: pointers

    Stefan Ram <-berlin.de> wrote:
    > (Jens Thoms Toerring) writes:
    > >And when you add a number to a memory address in assembler
    > >the result is the direct sum of that number and the address,
    > >while for a pointer it's the original value plus the product
    > >of the number and the size of the type of what the pointer
    > >points to.


    > I do not believe that this applies to functions pointers.


    > It might apply to object pointers. While one cannot say that
    > object pointers are memory addresses, one might say that
    > they are array addresses: p+1 points to the next object in
    > an array of objects of the type of *p.


    Yes, you're right, of course. I should have mentioned function
    pointers - or void pointers - those make it even more obvious
    that a "pointer" isn't "just a memory address".

    > However, some programs use only pointers, but do not use
    > pointer arithmetics. To understand such programs, it might
    > help to think of the pointers as being memory addresses.


    But then there's still the issue of what happens "under the
    hood" when dereferencing a pointer - in assembler you have
    to spell out how many bytes should be involved (readb, readw
    or readl etc. or similar and the same holds for writing) while
    with a pointer the compiler "knows" what's the correct thing
    to do.
    Best regards, Jens
    --
    \ Jens Thoms Toerring ___
    \__________________________ http://toerring.de
     
    Jens Thoms Toerring, Oct 15, 2011
    #7
  8. Lynn McGuire

    Jorgen Grahn Guest

    Re: pointers

    On Sat, 2011-10-15, Stefan Ram wrote:
    > (Jens Thoms Toerring) writes:
    >>And when you add a number to a memory address in assembler
    >>the result is the direct sum of that number and the address,
    >>while for a pointer it's the original value plus the product
    >>of the number and the size of the type of what the pointer
    >>points to.

    >
    > I do not believe that this applies to functions pointers.
    >
    > It might apply to object pointers. While one cannot say that
    > object pointers are memory addresses, one might say that
    > they are array addresses: p+1 points to the next object in
    > an array of objects of the type of *p.


    Speaking of understanding pointers, I'd like to quote parts of what
    gwowen wrote back in April, in
    <>:

    Speaking personally, I find it helpful to think of pointers as
    modelling two distinct concepts.

    i) A nullable, reseatable reference to a single (possibly
    polymorphic) object. I can use it to access the members of the
    base type to which it has been declared to point. Trying anything
    else is fraught with danger (even obtaiining a copy of the object
    (due to slicing)).

    ii) A bi-directional iterator into a contiguous collection of non-
    polymorphic objects. Subject to staying within the bounds (or just
    off the end) I can increment, decrement to iterate over the
    collection, access members or otherwise manipulate however I like.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, Oct 15, 2011
    #8
  9. Lynn McGuire

    Pavel Guest

    Re: pointers

    Stefan Ram wrote:
    > (Jens Thoms Toerring) writes:
    >> And when you add a number to a memory address in assembler
    >> the result is the direct sum of that number and the address,
    >> while for a pointer it's the original value plus the product
    >> of the number and the size of the type of what the pointer
    >> points to.

    >
    > I do not believe that this applies to functions pointers.
    >
    > It might apply to object pointers. While one cannot say that
    > object pointers are memory addresses, one might say that
    > they are array addresses: p+1 points to the next object in
    > an array of objects of the type of *p.
    >
    > It should not only add the size to the memory address, but
    > also take care of alignment requirements.
    >
    > However, some programs use only pointers, but do not use
    > pointer arithmetics. To understand such programs, it might
    > help to think of the pointers as being memory addresses.
    >

    Speaking of pointer idiosyncrasies in C/C++ here is a good open-ended "interview
    question":

    "would you use a pointer or intptr_t as a key for std::set"?

    It's somewhat surprising how far you can go from it.

    -Pavel
     
    Pavel, Oct 16, 2011
    #9
  10. On Oct 14, 10:43 pm, (Jens Thoms Toerring) wrote:
    > Szyk <> wrote:


    > > >> The pointers in Pascal was a mystery for me.

    >
    > > > Find a copy of Cooper and Clancy's "Oh Pascal!" Best explanation of
    > > > pointers I ever read.

    >
    > > The best explanation for pointers:
    > >  >>>Pointers are memory adresses.<<<

    >
    > > No less no more, no bs. Just asm experience...

    >
    > There's more to pointers than just being memory addresses -
    > a pointer also comes with a type that controls how it is de-
    > referenced or what happens when an (integer) number is added
    > to it. If a pointer would be identical to an assembler memory
    > address each dereference would (as it is in assembler) require
    > specifying how many bytes at that address must be fetched.
    > And when you add a number to a memory address in assembler
    > the result is the direct sum of that number and the address,
    > while for a pointer it's the original value plus the product
    > of the number and the size of the type of what the pointer
    > points to.
    >
    > Thus pointers are a higher-level constructs and not just mere
    > memory addresses. There would be no need for pointer casts in
    > C++ (or C) if pointers would be just memory addresses.


    I found assembler experience little help with C's pointers

    I found the syntax confusing. I'd come from pascal and understood
    pascal. I'd even briefly encountered BCPL and I understood BCPL
    pointers. (hell, I'd even seen Algol-68's dreadd ref ref ref ref...
    and understood *that*). But C's wierd declaration matches usage just
    baffled me.

    I think the explanation

    "int *p; not only means p is an int*, but also that *p is an int"

    finally enlightened me.
     
    Nick Keighley, Oct 17, 2011
    #10
  11. Re: pointers (was: RIP Dennis Ritchie)

    On Oct 15, 2:12 am, -berlin.de (Stefan Ram) wrote:
    > (Jens Thoms Toerring) writes:
    >
    > >And when you add a number to a memory address in assembler
    > >the result is the direct sum of that number and the address,
    > >while for a pointer it's the original value plus the product
    > >of the number and the size of the type of what the pointer
    > >points to.

    >
    >   I do not believe that this applies to functions pointers.


    how do arrays of function pointers work?

    >   It might apply to object pointers. While one cannot say that
    >   object pointers are memory addresses, one might say that
    >   they are array addresses: p+1 points to the next object in
    >   an array of objects of the type of *p.
    >
    >   It should not only add the size to the memory address, but
    >   also take care of alignment requirements.
    >
    >   However, some programs use only pointers, but do not use
    >   pointer arithmetics. To understand such programs, it might
    >   help to think of the pointers as being memory addresses.
     
    Nick Keighley, Oct 17, 2011
    #11
  12. Lynn McGuire

    none Guest

    Re: pointers

    In article <4e9a1972$0$32193$c3e8da3$>,
    Pavel <> wrote:
    >
    >Speaking of pointer idiosyncrasies in C/C++ here is a good open-ended "interview
    >question":
    >
    >"would you use a pointer or intptr_t as a key for std::set"?
    >
    >It's somewhat surprising how far you can go from it.


    I don't generally think that trivia questions are very good for
    identifying good programmer. At best, they would identify peoples
    with good memory for trivia. This may or may not indicate a good
    programmer.

    As far as I am concern, seeing either of them in a code review is
    "code smell" and would be treated as such.

    Yannick
     
    none, Oct 17, 2011
    #12
  13. On 17.10.2011 12:00, Nick Keighley wrote:
    > I think the explanation
    >
    > "int *p; not only means p is an int*, but also that *p is an int"
    >
    > finally enlightened me.


    Well, problem is:

    int p[5];

    not only means p is an int[5], but also means p[5] is the first number
    in the array, that _isn't_ int (cause it's a faulty memory access).

    HTH,
    Markus
     
    Markus Wichmann, Oct 18, 2011
    #13
    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. Spiros Bousbouras
    Replies:
    22
    Views:
    1,410
    Charlie Gordon
    Sep 13, 2007
  2. Ioannis Vranos
    Replies:
    4
    Views:
    379
    Ioannis Vranos
    May 16, 2009
  3. C learner

    Query from Dennis Ritchie

    C learner, Mar 29, 2011, in forum: C Programming
    Replies:
    6
    Views:
    386
    James Harris
    Apr 4, 2011
  4. Bradley K. Sherman

    Dennis Ritchie Has Died

    Bradley K. Sherman, Oct 13, 2011, in forum: C Programming
    Replies:
    28
    Views:
    983
    luser- -droog
    Oct 18, 2011
  5. markspace

    [OT] Dennis Ritchie dies at 70

    markspace, Oct 13, 2011, in forum: Java
    Replies:
    37
    Views:
    999
    B1ll Gat3s
    Nov 7, 2011
Loading...

Share This Page