Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #10835 > unrolled thread

RIP Dennis Ritchie

Back to article view | Back to comp.lang.c++

Contents

  RIP Dennis Ritchie Leigh Johnston <leigh@i42.co.uk> - 2011-10-13 15:38 +0100
    Re: RIP Dennis Ritchie "A" <a@a.a> - 2011-10-13 16:43 +0200
    Re: RIP Dennis Ritchie Paul Kuriakose <paul.kuriakose@comcast.net> - 2011-10-13 10:45 -0400
    Re: RIP Dennis Ritchie Lynn McGuire <lmc@winsim.com> - 2011-10-13 14:22 -0500
      Re: RIP Dennis Ritchie Donkey Hottie <donkey@fredriksson.dy.fi> - 2011-10-13 22:53 +0300
        Re: RIP Dennis Ritchie red floyd <no.spam.here@its.invalid> - 2011-10-13 17:23 -0700
          Re: RIP Dennis Ritchie Szyk <szyk100@o2.pl> - 2011-10-14 19:21 +0200
            Re: RIP Dennis Ritchie jt@toerring.de (Jens Thoms Toerring) - 2011-10-14 21:43 +0000
              Re: pointers jt@toerring.de (Jens Thoms Toerring) - 2011-10-15 22:27 +0000
              Re: pointers Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-10-15 22:52 +0000
              Re: pointers Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2011-10-15 19:38 -0400
                Re: pointers yatremblay@bel1lin202.(none) (Yannick Tremblay) - 2011-10-17 10:46 +0000
              Re: pointers (was: RIP Dennis Ritchie) Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-10-17 03:01 -0700
              Re: RIP Dennis Ritchie Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-10-17 03:00 -0700
                Re: RIP Dennis Ritchie Markus Wichmann <nullplan@gmx.net> - 2011-10-18 10:35 +0200

#10835 — RIP Dennis Ritchie

Father Of C And UNIX, Dennis Ritchie, Passes Away At Age 70.

[toc] | [next] | [standalone]

#10836

printf("Goodbye World!"); 

[toc] | [prev] | [next] | [standalone]

#10837

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

It is a sad day indeed.

[toc] | [prev] | [next] | [standalone]

#10839

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

[toc] | [prev] | [next] | [standalone]

#10840

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.

[toc] | [prev] | [next] | [standalone]

#10841

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.

[toc] | [prev] | [next] | [standalone]

#10844

>> 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...

[toc] | [prev] | [next] | [standalone]

#10855

Szyk <szyk100@o2.pl> 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  ___      jt@toerring.de
   \__________________________      http://toerring.de

[toc] | [prev] | [next] | [standalone]

#10871 — Re: pointers

Stefan Ram <ram@zedat.fu-berlin.de> wrote:
> jt@toerring.de (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  ___      jt@toerring.de
   \__________________________      http://toerring.de

[toc] | [prev] | [next] | [standalone]

#10873 — Re: pointers

On Sat, 2011-10-15, Stefan Ram wrote:
> jt@toerring.de (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
<57d23fe9-b1e2-483c-a2da-f327d8025503@v10g2000yqn.googlegroups.com>:

    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   .

[toc] | [prev] | [next] | [standalone]

#10877 — Re: pointers

Stefan Ram wrote:
> jt@toerring.de (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

[toc] | [prev] | [next] | [standalone]

#10918 — Re: pointers

In article <4e9a1972$0$32193$c3e8da3$670ba073@news.astraweb.com>,
Pavel  <pauldontspamtolk@removeyourself.dontspam.yahoo> 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

[toc] | [prev] | [next] | [standalone]

#10916 — Re: pointers (was: RIP Dennis Ritchie)

On Oct 15, 2:12 am, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> j...@toerring.de (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.

[toc] | [prev] | [next] | [standalone]

#10917

On Oct 14, 10:43 pm, j...@toerring.de (Jens Thoms Toerring) wrote:
> Szyk <szyk...@o2.pl> 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.

[toc] | [prev] | [next] | [standalone]

#10962

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c++

csiph-web