C / C++ / MFC

14-Jan-04 20:28

I'm not generally known as a stupid guy, but I'm really confused by this. I've been programming for 25+ years, but I've only recently tried to add C++ to my list of proficiencies, and I'm embarrassed to ask, but I'm going to anyway.

I see code that uses the . operator to reference member functions as often as I see the -> operator used for what appears to me to be the same purpose. What the heck is the difference? Can someone explain to me, without the utterly useless Microsoft technical babble, what the difference in usage is? I know it's trivial to you experts, but I have a (hopefully) temporary blind spot that is blocking me from progressing on my journey of discovery on the path of C++ enlightenment.

Please use small words appropriate to my small understanding for your reply... And, Thank you, for helping me to overcome this silly mental block. I'm usually good at spotting patterns, but this one has me stumped. Blush | :O

"Another day done - All targets met; all systems fully operational; all customers satisfied; all staff keen and well motivated; all pigs fed and ready to fly" - Jennie A.

StHubi14-Jan-04 20:54

StHubi

14-Jan-04 20:54

The . operator is for non-dynamic variables. The -> operator is used for pointer variables.

I think you know what a pointer is, don´t you?

"Have no fear, the saint is here!"

Cyberizen14-Jan-04 20:54

Cyberizen

14-Jan-04 20:54

well the . and the -> actually do the same thing they server the same purpose but the difference is that the '.' (dot operator) is used when are dealing with a NORMAL object while the -> operator is used for a POINTER object like check this little snippet below

class foo
{
public :
int i;
};
when making an object of this class
foo myobject;
myobject.i = 0; //this is the normal way to access the i variable

now look at this object
foo *pobject; //now this is a pointer to object
pobject->i = 1; //this is way i will be accessed

lobanovski14-Jan-04 20:55

lobanovski

14-Jan-04 20:55

small words? you got em Smile | :)

// a header file
class A
{
public:
A();
~A();

void foo();
};

// a source file

int main(int, char**)
{
A a_object;
A* a_[ointer_to_the_object = new A();
a_object.foo();
a_pointer_to_the_object->foo();
return 0;
}

you see? when you deal with a pointer - you use -> operator......

debug - is my life style

alex.barylski14-Jan-04 20:57

14-Jan-04 20:57

Roger Wright wrote:
see code that uses the . operator to reference member functions as often as I see the -> operator used for what appears to me to be the same purpose. What the heck is the difference?

To the best of MY understanding Smile | :)

The member selection operator -> is used whenever the expression before is coupled with an indirection operator *

// No indirection
CMyObject myObj;
myObj.Test();

// Using indirection
CMyObject* myObj;
myObj->Test();

You can acheive the same thing using

CMyObject myObj;

(*myObj).Test();

Basically when you use -> or *. are accessing members indirectly with a pointer.

The word of the day is legs, let's go back to my house and spread the word Poke tongue | ;-P

Roger Wright14-Jan-04 21:28

14-Jan-04 21:28

Thank you for the only marginally comprehensible answer of the lot. Frankly, pointers drive me over the edge, and make me long for the resurgence of Pascal, the only language that's made any sense in the past 20 years or so. Indirection was handy in the ASM days, and I loved using it. But it seems an absurd layer of obscurity when applied to modern languages. I really hate that part of C++.

"Another day done - All targets met; all systems fully operational; all customers satisfied; all staff keen and well motivated; all pigs fed and ready to fly" - Jennie A.

Antti Keskinen14-Jan-04 22:07

Antti Keskinen

14-Jan-04 22:07

Well, perhaps I'll add my knowledge to the heap.

Consider the following: you have an object of some type. Let's name this type 'Roger', and let it have an attribute called 'Age' (No sarcasm intended !)

Now, if in your code, you created a static object, you would use Roger MyRoger declaration. This would create a static object for you. You would then access the member variable by using MyRoger.Age = 30, for example.

Let's take a step beyond and consider a pointer. See in front of yourself a 3D-space. In this space, you see the MyRoger-object standing at some point. Then, you create a pointer of type Roger using a declaration Roger* pToMyRoger = &MyRoger. Now, the pToMyRoger pointer points towards the MyRoger object, just like an extended finger.

A static object is aware of two things: what it is, and where it resides. A pointer to any object is aware of two things as well: where it resides, and what is to be found in that location.

For a more in-depth scenario, consider that your Roger-object (MyRoger) reserves a place for itself in memory (&MyRoger). If you issued MyRoger.Age, the compiler would get the address of MyRoger, move forwards from there to the Age variable, and retrieve it's contents. If you used a pointer, then the compiler would take the address you give to that pointer, and ASSUME that the object found from that address is the one specified by the type of the pointer (Roger*). It would then search for the Age variable again, and retrieve it.

Then to the term 'dereferencing'. When you have pointer to the object Roger (pToMyRoger), you can dereference it to an OBJECT of type Roger by using the asterisk (*) operator. For example, this declaration (*pToMyRoger).Age is the same thing as MyRoger.Age. As you might guess, *pToMyRoger equals to MyRoger hence leading us to the following conclusion: the dereferencing operator (*) can sometimes be named as the 'contents-of' operator. Thus, the contents of pToMyRoger (*pToMyRoger) equals to the object MyRoger (MyRoger). Does this make sense ?

In the conclusion, the '.' and the '->' operators behave similarly, but they are used in different contexts. For example, the following declarations do all the same things

MyRoger.Age = (*pToMyRoger).Age = pToMyRoger->Age = (&MyRoger)->Age

I am not sure about the final declaration, as I have never tested it. But, it should work according to the C++ language syntax, to which we will not dive right now Big Grin | :-D

-Antti Keskinen

----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.

Roger Wright15-Jan-04 4:30

15-Jan-04 4:30

Thanks! That helps clarify things quite a bit. Smile | :)

"Another day done - All targets met; all systems fully operational; all customers satisfied; all staff keen and well motivated; all pigs fed and ready to fly" - Jennie A.

alex.barylski14-Jan-04 22:46

14-Jan-04 22:46

I just finished writting a bunch of verbage and an error occurd when I sent it Frown | :(

And I don't think it sent...sux when that happens Smile | :)

Anyways...you've helped me more often then not during my times here at CP so any time I can help back i'm more then happy.

Cheers Smile | :)

The word of the day is legs, let's go back to my house and spread the word Poke tongue | ;-P

[James Pullicino]15-Jan-04 1:35

[James Pullicino]

15-Jan-04 1:35

The feelings you are having towards c++ are normal and understandable for a person trying to learn the language. Once you fully grasp the concepts and advantages (as well as disadvantages) of pointers you will view them in a much different light for sure.

Roger Wright15-Jan-04 4:32

15-Jan-04 4:32

I suppose so, though I haven't yet found any use for a pointer, nor any need to use one other than to comply with the declaration of some class or other. Sigh | :sigh:

"Another day done - All targets met; all systems fully operational; all customers satisfied; all staff keen and well motivated; all pigs fed and ready to fly" - Jennie A.

filter control like Outlook Express message rules

David Crow15-Jan-04 7:58

David Crow

15-Jan-04 7:58

Roger Wright wrote:
But it seems an absurd layer of obscurity when applied to modern languages. I really hate that part of C++.

Technically, pointers existed long before C++.

A rich person is not the one who has the most, but the one that needs the least.

Re: Really Dumb Reply

Monty²15-Jan-04 0:14

Monty²

15-Jan-04 0:14

Not knowing the difference between . and -> does not make you a stupid guy Smile | :)

and Knowing the difference between . and -> does not make us any smarter either Smile | :)

you are OK Rose | [Rose]

C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do, it blows away your whole leg

quzi14-Jan-04 20:07

quzi

14-Jan-04 20:07

Hi,

Is anyone knowing if there is being code to do filter rules like the Outlook Express? Is a nicely way to building informations, and I would liking to do this.

Thanking you with flipping toes

32 and 64 bits

lobanovski14-Jan-04 20:07

lobanovski

14-Jan-04 20:07

hi everybody!

i was asking this question in "general" forum, but got no replays...
----

i've got an opportunity to upgrade my system to amd 64 3200+. it's preaty cheap and it would be stupid to miss it, but... i do developing under windows and linux and MOST clients of mine are the users of 32-bit architecture. in the specs of the cpu i found misterious phrase "supports both simulteniously 32 and 64 arc's" huh? so, my dilema is - miss or not miss good chance for the upgrade. What are the issues will i face after upgrade to 64 (with regard to developing under win .NET studio)? What are the consiquences for my end-users? I mean only windows users, if they have win2k (just for example!) and 32-bit cpu (pIII), and they try to run a binary that was built on my winXPpro 64-bit cpu, will they have problems?

please, share your opinion and experience, i really need it!

thanx
alex

debug - is my life style

Re: 32 and 64 bits

alex.barylski14-Jan-04 21:07

14-Jan-04 21:07

It's been a while since I read my A+ book so forgive me if i'm wrong.

I believe 32 and 64 bit arc's are usually determined by the following factors:

1) Register size
2) Number of bits computer can transer per MOV instruction...your bus bandwidth I guess Blush | :O

Anyways, most computers now are 32 bit because the internal registers are all 32 bit with I believe the exception of a few floating point registers which are 48 or 128 or something...

So you shouldn't have any backwards incompatiability issues when developing on a 64 bit arc becuz so long as your compiler compiles using common 32 bit instruction set it should run on your 64 bit machine or my 32 bit one. Kind of like how I could use 16 bit MOV instruction on my computer, but I could only move 16 bits at a time, whereas I could also use a 32 bit MOV instruction, but now be able to move 32 bits.

.NET uses an intermediate language...I can't remember what it's called... IL maybe...?

Anyways...the .NET interpreter would determine which actual instruction to send the processor (I believe thats the idea behind .NET) so you shouldn't get any exception becuz of a bad instruction when you compile apps using .NET.

Cheers Smile | :)

The word of the day is legs, let's go back to my house and spread the word Poke tongue | ;-P

Re: 32 and 64 bits

lobanovski14-Jan-04 21:28

lobanovski

14-Jan-04 21:28

right, thanx Smile | :)

the scenario you've gave requires .NET being installed on the user's computer. or not?

debug - is my life style

Re: 32 and 64 bits

alex.barylski14-Jan-04 23:02