Re: couple of general questions

From: Gary Labowitz (glabowitz_at_comcast.net)
Date: 04/06/04 

Date: Mon, 5 Apr 2004 21:53:48 -0400

"Snake" <hana1@rogers.com> wrote in message
news:Jxmcc.22056$L_8.19596@news01.bloor.is.net.cable.rogers.com...
<<snip>>
> anyways, I regarding the pointers and
> reference thing.I thought that pointers are under the reference
category
> (and thats how it is in most of the websites) since pointers hold
the
> address of the object and thats what reference is(to you FRANCIS)

Okay, Snake. You DO have a misconception about the nature of
references.

A pointer is a type that contains an address of an object as its
value.
But a reference is not simply a constant pointer. The concept of a
reference is that a reference is an identifier that refers directly to
the same value as the identifier of the caller. In effect, the calling
function is passing the identifier and the called function uses a
different name for it. Example:

Calling function code:
     int myName = 17;
     passFunction(myName);
Called function code:
    void passFunction( type& differentName)
     { differentName = 20; return; }

When the called function uses the identifier "differentName" the
compiled code stores the value 20 directly into the variable that the
calling function uses the identifier "myName" for. They both refer to
the same object using different identifiers. That is all.

There is nothing in this description that forces the compiler to
generate the code using pointers to implement this action, although it
is probably the way all current compilers do it. Notice that the
compiled code, if it uses a pointer mechanism to refer to the value,
does all the dereferencing needed. The writer of the called function
does not have to use a parameter identifier with the * operator.

Now, my contention is that this is the kind of explanation a good book
would have (perhaps with more examples). To explain it here in this
detail and focus is like writing a book on-line. The fact is that many
web sites and books don't explain it this way is sad, but true. ACCU
is your friend, in that case.

I believe that others here have the same point of view with regard to
explaining, in great detail, the basics of the language.
If you (and anyone else) is unhappy with my explanation, then the
comp.lang.c++ newsgroup is probably the correct place to discuss this.
Have a good day. 

-- 
Gary

Relevant Pages

  • Re: Real World Flunks (Re: Why is Object Oriented so successful)
    ... AndyW wrote: ... "modeling the real world". ... CADD screen closely matches the object pointers in a typical real- ... I think the fact one has a reference to it ...
    (comp.object)
  • Re: The Java no pointer big fat lie!
    ... > reference types, it wouldn't be a good comparison. ... and what you can't - and there is a big difference in Java to C and C++. ... You cannot change it in the language itself, ... Thus I would distinguish pointers from ...
    (comp.lang.java.programmer)
  • Re: Pointers vs References: A Question on Style
    ... >> One good style rule is to never return null, ... Prefer references to pointers unless you need pointers' special ... The edit fields link to the XML via MVC. ... > 'funk', you should pass by reference, and catch errors at compile ...
    (comp.lang.cpp)
  • Re: C# equivalent to a smart pointer???
    ... My understanding is that the use of pointers in C# is strongly ... data sharing functionality similar to that provided by smart pointers in ... innately through the reference type. ... Whether this final action on the object can be done while disposing the ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Array comparison
    ... > Deep and recursive. ... the pointers and comparing their referents instead of comparing the ... >> arrays, then I think you also need to argue against assigning arrays. ... semantics (notably, reference counting). ...
    (alt.comp.lang.borland-delphi)