Will McQueen wrote:
> Thanks for the link. Here are the relevant portions:
> CListCtrl& GetListCtrl( ) const;
> CListCtrl& theCtrl = GetListCtrl();
>
> I'll ignore the "const" modifier for now, as its use confuses me at the
> moment.
>
> Here's a paraphrase of what you mentioned, as I understand it:
> 1) Using "type&" is sort of like using a pointer ("type*")


Sort of. They both point\refer to the same object.
References are more safe than pointers, one should always use a reference
instead of a pointer whenever possible.
A pointer can point to nothing. It can also point to different objects at
different times.
A reference must point only to one object and you HAVE to tie the reference
to the single object when you declare the reference.
       int &ref; //is invalid, will not compile.
       int *ptr; //is valid

Don't want to confuse you more but under the hood, references are
implemented using pointers, but we'll skip that for now.

2) By using "type&", a test for NULL is not needed


Yes.
When using pointers you'll typically write code like

void foo(int *ptr)
{
 if (ptr != NULL) //this is because ptr can point to nothing
     //do something
}

Also, ptr can point to an invalid memory location. You'll go past the NULL
check, but when you access the pointer, your program will bomb. Not
different from Java references, you will do similar thing when using user
defined types in Java right?

You don't have to worry about all these things when you use a reference
because a reference cannot be dangling, it MUST be tied to an object.

3) When using "type&" instead of "type*", you access the object's fields by
> using "." instead of "->"


Yes. Because a reference is nothing but an alias to the object variable.
int i;
int &j = i;
When you change j, you change i.
j is nothing but an alias of i, a rose by any other name.

Before I go on, please understand that I come from a Java background,


Since you know Java, C++ pointers are something like Java references.
AFAIK, Java does not have equivalent of C++ reference, but I could be wrong.

Maybe that makes it more confusing for you!

and my
> intent is to learn (re-learn) ANSI C -- thus my confusion with pointer-
> and
> address-related semantics in C. I have no interest in learning C++ right
> now,
> but it's definitely in my queue -- everything I refer to will be with
> respect to
> ANSI C. My intent is to take what I learn from C and use that knowledge to
> write
> Java programs that access C native code via JNI. I have a quite a few C
> books
> lying around here, including:
> a) ANSI C spec
> b) comp.lang.c FAQ list
> c) Rationale for International Standard -- Programming Languages -- C
> d) The New C Standard -- An Economic and Cultural Commentary
> e) The C Programming Language
> f) C in a Nutshell
> I'm currently jumping around between a, b, e, and f (mostly concentrating
> on f
> right now). For my C environment, I use Eclipse 3.3 with CDT and the gcc
> from
> cygwin on WinXP Pro.


If you are only interested in learning C for now and not C++, maybe you
should skip all this until you come to C++.
C and C++ are two different languages.

Now, back to C...


Back to C++ actually, the link is MFC, but we'll treat it as C++ for now.

>From the paraphrase, I have some questions...
>
> 1) Since "type&" is sort of like "type*", does this mean that I can cast
> between
> the two types?
> For example:
> CListCtrl& var1 = GetListCntl();


Returning a Reference

...might be rewritten as...

> CListCtrl* var1 = GetListCtrl();


Returning a Pointer

...or explicitly cast as:
> CListCtrl* var1 = (CListCtrl*) GetListCtrl();


err....no.

CListCtrl * GetListCtrl()
{
//mList is class variable
return &mList; // you are returning address of mList.
}

This is similar to:
int number;
int *ptr = &number;

CListCtrl & GetListCtrl()
{
//mList is class variable
return &mList; // you are returning mList reference, i.e. an alias of mList
or you can think of it as returning mList itself!
}

This is similar to
int &reference = number;

Of course, following is valid:

int number;
int &ref = number;
int * ptr = &ref; // all a pointer needs is an address. ref is nothing but
number here. You are assigning number's address to ptr

int &ref2 = *ptr; //all ref2 needs is a valid object to tie itself wtih


2) Let's assume that NULL is represented as integer 0.


In fact, it is.

If it's not necessary to
> check for NULL when using "type&", then what happens in the following
> scenario
> if GetListCtrl() returns NULL?
> CListCtrl& var1 = GetListCntl(); //GetListCtrl returns NULL (ie, 0x0)
> println("%d", var1.x); //assume that var1 represents an object with a
> field named "x" which we are accessing


You cannot have something like:
int &reference = NULL;
reference has to point to an object.

Actually, if you really want to shoot yourself in the foot, following will
compile and run:
int *ptr = NULL;
int &reference = *ptr;
reference++; //bomb!

My guess: I think that evaluating var1.x would attempt to access the value
> stored at field x from an object (ie, from the var1 obj) whose address
> starts at
> 0x0... probably resulting in some kind of exception (I haven't tried this
> yet).... but it probably wouldn't be a NullPointerException since I don't
> think
> that 0x0 would be interpreted as a NULL value, due to using "CListCtrl&"
> as the
> type instead of "CListCtrl*".

3) In ANSI C, what is meant by an "object"?


You are mixing C and C++ below. They are not the same language.
In C++ world: typically object is a user defined type like class, struct.
But Scott Meyers calls even default data types like int, char as objects.
In OOPS language: Object is an instance of a class.

My advise to you is to skip learning C++, concentrate only on C if that's
what you want.
Take up C++ when you come around to it.


According to the "C in a Nutshell"
> book: "the term _object_ refers to a location in memory whose contents can
> represent values. Objects that have names are also called _variables_.:
> Okay, so it sounds like in ANSI C, an object can be a primitive like a var
> of type "int", right? Or, must that int type be wrapped in a struct in
> order to
> be considered an object? The "." operator "dereferences an object" (not
> sure if
> I have the terminology right) so that a field or function of the object
> can be
> accessed, right? I don't recall ever being able to use the "." operator on
> a var
> of primitive type (not that it would be necessary, since primitives are
> not
> composite types...).
> So, I'll assume for now that in C, the term "object" refers to a
> non-primitive type. A "variable" is thus the object's name, and represents
> the
> entire object (as opposed to its starting addr). The _address_ of the
> variable
> is the location in memory at which the object starts (assuming that the
> object
> is a contiguous collection of one or more memory slots). You get the addr
> by
> taking "&var1". So if var1 is of type int, then &var1 represents the
> starting
> address of the object whose size and type are determined from the int
> type.
> Let's say that var2 is declared like this:
> CListCtrl& var2;
> Here, I'm not sure how to parse-out the type from this statement. The
> variable name is var2, so the type must be what's left, which is
> "CListCtrl&",
> right? I don't think that the var would be "&var1" and its type be
> "CListCtrl"...
>
> So confused...
>
> I appreciate any help on this, including any links/articles that might
> help
> clarify this confusion.
>
> Regards,
> Will


Hope that helps.

Cheers
- Ananth


[Non-text portions of this message have been removed]

Reply via email to