objects and methods

In general, a member function has privileged access to the member variables of the object instance. In many OO languages members can be marked public and private, and member functions are the only ones allowed to access and modify private members. Non member functions will not access member variables - even if only by convention in languages that don't support member access control.

Most languages have special syntactical support for member functions, so that calling them is different to calling regular functions. Likewise, the object on which the function was called is made available through a special variable or keyword rather than an explicit parameter.

Finally, member functions can be overridden in derived classes (sometimes requiring explicit keywords). When such a member function is called, the runtime will resolve to the correct member function, even if the static type of the object is different.

Of course, you can have languages where some of the above isn't true, and you can write member functions which do not touch an objects member data.

As for your request for examples, which language are you using?

At a very basic level, the only difference between a free function and a member function is that the member function receives a 'this' pointer - i.e. a pointer to the object it is a member of. This pointer allows it to access and modify the state of the object.

In C++, the 'this' pointer is passed to the function automatically, without any effort on the part of the programmer. Some languages (such as Python) require the programmer to explicitly specify the this pointer, instead.

Quote:

Original post by conejo5991 But I would like to know how it is associated.

Methods have a hidden parameter called this which points to the object on which the method was invoked.

So if you say someobject.somemethod(1, 2, 3), inside the method this will point to someobject -- this enables you to manipulate its state.

Thanks for the responses. I am trying to program in C++, but I am hoping to learn PYTHON eventually because you don't seem to have to declare as much.
But with all your attempts to help me, I still have the lingering question, which is this:

Does the method put values into the variables of thre object,

which non-OOP user-defined functions did except for VOID.

Or does, in general, the method "MODIFY" the object some other

way? How does it modify it? I swear, that's the issue upon which

I am completely lost. What does the code in the method do to the code

in the object, as a general rule. Or, do I have the idea roughly

correct already, that the method will inject the right types of variable

returns into the appropriate variables in the object respectively?

Thanks again for taking the time to help me clarify this situation.

Someday I'll get it, as a programming aspiration, and as an all-pervasive

statement with respect to life itself. Although, that's more for another forum.

Laugh out loud :)

Quote:

Original post by conejo5991 What does the code in the method do to the code in the object, as a general rule.

What? There is no "code in the object". An object consists of data, and there are methods that manipulate that data.

For example, if you have a class Person with a member variable name and a member variable age, then each object of that class will have its own name and age, but the methods exist only once, no matter how many objects you have.

When you invoke a method on an object, that method knows which object to modify thanks to the this pointer, and it has access to all the member variables of said object.

Here's a contrived, untested example of a Person class.

Oh! That's strange. I was thinking that the Class more or less defined things.

Then the OBJECT was the part of OOP where you laid down the core code.

And the Member Functions did the math so you could use the variables

within the object. From the last Reply it seems now that OBJECTS

are filled with only DATA, which reminds me of the READ/ DATA

statements from dinosaur BASIC. Boy, now I have to begin to

retool my whole perception of what's going on.

So if an object is only a set of data, then where do the primitive line

commands get used, only in MEMBER FUNCTIONS?

Thanks again.

Quote:

Original post by conejo5991 Oh! That's strange. I was thinking that the Class more or less defined things.

It does. The class defines the member variables and the methods at compile-time. At runtime, each object has its own member variables, but the methods are not unique for each object (that would be a waste of space). Each method manipulates the member variables of the object on which it was invoked.

Quote:

Original post by conejo5991 So if an object is only a set of data, then where do the primitive line commands get used, only in MEMBER FUNCTIONS?

I have absolutely no idea what you are talking about. What is a primitive line command?

Verbal glitch, by primitive line commands,

I was meaning C++ code using what I thought they called

Primitive Types, just the rudimentary coding such as:

cout>>, or cin>>, or if/else, or while/do, for/next

That kind of thing. All things algorithmic.

Once you get OOP going, the member function at least has these things right?

But two or three replies ago, someone said that

OBJECTS have only data. I was under the mistaken impression that

OBJECTS have these primitive algorithmic types within them.

Is that true?

And by the way, is there such a thing online as a simple C++ OOP

course, maybe even free, but you can't expect too much I guess,

where the instructor could possibly clear all these things up for me,

and then I could really get a jumpstart on coding?

Quote:

Original post by conejo5991 Once you get OOP going, the member function at least has these things right?

Anything you can do in a normal function you can also do in a member function.

Quote:

Original post by conejo5991 But two or three replies ago, someone said that OBJECTS have only data. I was under the mistaken impression that OBJECTS have these primitive algorithmic types within them. Is that true?

The data can consist of these primitive types... Look at my Person example. A person consists of a string, an int and a set of pointers to other Persons. int is a primitive type.

And "objects have only data" means that at runtime, the data is what takes up space. The methods logically BELONG to the object, but the object does not HAVE them (you were talking about "code in the object" which is clearly wrong). The data and the methods belong together, and that's why you find them bundled together in classes. Maybe you are just confusing classes and objects?

Quote:

Original post by conejo5991 cout>>, or cin>>, or if/else, or while/do, for/next That kind of thing. All things algorithmic.

cout and cin are not 'primitive' nor are they 'types. They aren't primitive in the same way if/else and while/do are. None of those things are types either, 'int' and 'float' are types. Also, there is no 'next' in C++ so I'm not sure where you got that from. cout and cin are objects provided by the compiler vendor that allow the program to interact with a console. If you don't need to interact with the console you don't need cout or cin.

Quote:

Once you get OOP going, the member function at least has these things right?

Many classes will use some or all of those things, but it's not really a requirement so much as a byproduct of how programming works. One thing that many programs don't actually use in the 'real world' is cout and cin. It's almost impossible to avoid ifs, whiles, and fors in a program though. An individual member function doesn't necessarily have to use any of that to work even if most will. It depends on what the member function does. Sometimes the member function will just do do some math or even just return data. It depends and it's not a good idea to make hard and fast 'rules' about what a program 'must' have.

Quote:

But two or three replies ago, someone said that OBJECTS have only data. I was under the mistaken impression that OBJECTS have these primitive algorithmic types within them. Is that true?

As you said in your original post "a member function is associated with an object". Associated is kind of a loose term, so in some sense an object could have 'algorithms in it', but that's generally not the most productive way to think about it. An object has data and associated member functions, but the member functions aren't really part of an object. They are however associated with all of the objects of that type(ie, the class) and the member functions operate on individual[i/] objects when invoked.

This concept can be further illustrated by comparing regular member functions to static member functions. Static member functions don't operate on an object they operate on all objects(ie, the class). As such a static member function can't modify member variables of individual objects(how would the program know which members to modify?), only static member variables which are shared between all objects. I wouldn't be surprised if that confuses you further if so I'm sorry.

All that aside, in many cases the distinction between 'an object is only data with associated member functions' and 'an object is data and member functions' won't really matter. But eventually you'll do something that won't make sense unless you remember that there is one set of code shared by multiple sets of data.

Quote:

And by the way, is there such a thing online as a simple C++ OOP course, maybe even free, but you can't expect too much I guess, where the instructor could possibly clear all these things up for me, and then I could really get a jumpstart on coding?

There's not really any place where someone will work with you one-on-one. But if you have further questions you can ask here. The closest thing I can think of to what you want is right here at gamedev in the "CPP Workshop" forum. The concept was to have a workshop where everyone would follow along in the same book and post questions and get answers. You can post a question, but you might not get answer for awhile as there isn't heavy traffic there any more. However, there's a good chance someone has already had the same questions as you so you could just read the threads associated with a particular chapter for questions and answers other people had.

Hope this helps.

But data can contain what used to be considered line commands.
Is that correct?
Isn't it true, then, in a nutshell,
that the class declares, the object puts forth
the arguments, and the methods do most of
the mathematics?
Of course, unless you use a void function
where it does what an object would do,
but for some reason is an extra subroutine?

I don't disagree with your concept of non OOP statements
because eventually the teacher I had said to tle class
that what we thought were line commands were actually
kinds of variables, or as you say, classes.
True, but my problem or point of view is that
most of the programming I did years ago
was with what they used to call line commands
in early 80's BASIC, with line numbers even.
What a trip. But now I see it as algorithmic programming,
and I have to get comfortable with OOP.

I'm not trying to be confusing or anything,
but I see the object as something similar to
what I USED TO call line commands,
although even I have been shown that ultimately
they are not. It just helps me in my conceptualization
at this point so I can get this clear picture I need.
Call it stubborness if you will.
I also have a creative side, which you probably do too
if you can write in OOP.

On the other hand, is there a book you know of
that makes all these terms really clear,
maybe even written for kids.
And has really simple broken down examples
and enlightening projects?
Because to be honest with you,
I do much much better when I study math,
science, and even programming,
with layman's books. I'm just not good with
technical terms even though my vocabulary is fairly decent.

Can you please stop
writing like this?
I really want to help you
but I can't bring myself
to read whatever you're
writing because it's really
annoyingly layed out.

Dear Nullsquared, If you could get me to understand my problem with how an method is associated with an object, then, of course I will do my best to change my wording schema. Could you then put forth for me, the appropriate framework into which I should alter my questioning schemata? Right now I don't have a framework other than that which comes forth in an intuitional manner
which seems to me to be in conformity to a move from algorithmic thinking into a more OOP frame of mind, because I have even myself noticed that some of the questions I post, and I have posted other places, will actually cause me to be enlightened toward to resolution of this matter, even though I only considered it to be a question. But when I write out the thought process in a question form of statement, then the rereading of it, or merely considering of it, will actually bring some kind of enlighenment towards the full resolution of the problem, of which I must be ignorant, otherwise I would not pose the question in gthe first place. So it seems to me that I am making my best attempt to move forward positively on the ignorance-enlightenment continuum.
But seriously, and I wasn't trying to be too unserious previously,
If you can give me a more organized way to put forth a question, to which I don't yet have an answer, which can help other programmers who are reading my question and trying to help me, to better understand even what I am trying to actually say, then most assuredly, I will do my best to follow such a path.
I guess this has something to do with why my high school English papers didn't get thde best of grades, even though I spent hours writing them.
So, even your response to this reply could actually move me towards getting better in language expression, which could go even further than programming skills by themselves.

Quote:

Original post by conejo5991 But data can contain what used to be considered line commands. Is that correct? Isn't it true, then, in a nutshell, that the class declares, the object puts forth the arguments, and the methods do most of the mathematics? Of course, unless you use a void function where it does what an object would do, but for some reason is an extra subroutine?

I'm sorry to say this, but I have absolutely no idea what you are talking about. Maybe you should just grab a beginner's C++ book and start programming. I suggest "Programming: Principles and Practice using C++" and "C++ Primer" and "Accelerated C++". Pick any of these and start.

I'll give it one last shot at trying to explain. To the compiler these two programs are effectively identical:

You wouldn't say that in the first example that the struct Foo has the functions SquareFooX and SetFooX. In fact, in back-in-the-day C++, C++ compilers just converted the 2nd source code into the 1st source code and then used a C compiler on the converted code.

And while I'm rereading your original post, I see you asked for a 'bonehead example of an object interacting with a member function'. See this line?

foo.SetFooX(5);

SetFooX is the member function interacting with the object foo.

As for your other question, you can't make the member function user defined in C++. That all happens before you compile. If you want that functionality in C++ you're in for a world of hurt because it doesn't exist. This is why people use languages that support reflection when they want this. As you can see in the examples C++ is not listed. If you want reflection in C++ you basically need to embed a scripting language into your program. At this stage in you're learning I suggest you forget about it.

Hi conjeno,

sorry didn´t follow the thread as a whole, but what i understood is, that you are greatly confused. It seems you are approaching the whole subject too technically.

Object oriented programming is an approach to make programming more intuitive for human programmers. In everyday life you deal with objects all the time. Objects may be trees, cars, animals, people whatever. Objects have particular properties,
like smell, color, sound etc. This is conceptual the same as the programming term "object property" or "object variable".
Particular objects are also able to perform actions like humans and animals and machines. When an object performs an action, the state of the world may be changed, the object may either affect itself or any other object. You may
understand actions as the programming term "method". A method is a sequence
of actions to achieve a certain goal in the world and in achieving that goal
may affect other objects. If you would like to still your hunger, a method would be to cook, or go to McDonalds.

An object performs an action, when you ask it to do so. You send the object a message. If you have an object of type "car" you could send it different messages like car->turnEngines(On/off); car->steerWheel(left/right);
The important point is, that it has an easy intuitive interface to the outside,
but is complicated in the inside. The car has subobjects, such as wheels, the engine an electric system. But it is completely hidden by a simple interface.
That is what makes OOP so powerful. Also it divides your project into dozens of different objects, which may each be understood by its own, instead of one big mess of a program.

Last but not least you may asked, what classes are for. These are out of everyday usage also. Say you have red, a blue and a green pencil. It is the same concept "pencil" regardless the color. You would only introduce one class in your program to model this - a class called "pencil" with an attribute or property "color". You may now instance this concept into arbitray indivudal objects without repeating yourself over and over again. You don´t need to mention the shape and the function of the pencil again, just its particular attributes.

Hope this helps a bit. This is by no means complete, just a quick flow of my mind to get you a bit on track. Sorry, i can´t write more. My advise is don´t think too technically ;-)

Cheers,
Frederick