need some help (classes)

i am new at programming and try to teach myself C++. first i searched some tutorials and started to read. all of them explain how loops, inputs, outpus and that stuff work but there is no one that explains, in a way that i can understand, what a class or a object is. if u can explain me what it is or send me some links where i can find explanations please do so. but consider that i do not know much about programing at all and need simple explanations, without words that require knowledge to be understood.
thanks a lot.

Hi,

You could check out the book "Thinking in C++" by bruce eckel. Its a cool book to learn C++, especially since its free on the net.


int i;

If int were to be a datatype created by the user then you would class it a class.

i is a variable of type int...... similarly variables of a class are called objects

// creating a user defined databype called x
class x
{
char ch; // these are called data members
int i;
public:
x() {
ch = '\0';
i = 0;
}
// functions inside a class are called member functions
};

int main()
{
x ob;

// here x is the class and ob is the object of class x
return 0;
}

Hope it gives you a quick start to your understanding of classes and objects

classes are ways to describe things. Objects are individual instances of a class. Let's say you want to describe a car. In english you can say a car has 4 tires (usually), a steering wheel, and engine, some doors. It can run at a certain miles per hour and it can go a certain direction. To change this into C++ you can do this:

Code:

---

enum Direction {north, south, east, west};
class Car
{
  public:
    int numTires;
    int numSteeringWheel;
    int sizeEngine;
    int numDoors;
    int speed;
    Direction direction;
    void changeSpeed(int);
    void changeDirection(Direction);
};

---

That's a generic description of what a car contains and what it can do using a class C++. Note that descriptions of what it contains are usually described by variables, and what it can do is described by functions. But what about any given car. It might have 2 doors instead of 4, it might havea big engine or a small one. It might be heading East, not West. How do you know. Well, you are in charge. You decide by setting it up the way you want using a instance of the class Car (otherwise known as an object).

Car puttputt;
puttputt.numTires = 4;
puttputt.numSteeringWheel = 1;
puttputt.numDoors = 4;
puttputt.sizeEngine = 100;
puttputt.speed = 0;
puttputt.direction = East;

Then how do you change the speed or direction? You use the functions in the class:
puttputt.changeSpeed(23);
puttputt.changeDirection(North);

where the definitions are defined as:

Code:

---

void Car::changeSpeed(int x)
{
  speed = x;
}

void Car::changeDirection (Direction _direction)
{
  direction = _direction;
}

---

So far this is a pretty rough description of a classes. You can, should, and will get more sophisticated in their use. The text previously recommended is good, but I think it is more useful if you know some C first. For someone not knowing C I recommend the online version of Teach Yourself C++ in 21 days by Liberty if you want an online text. I still feel more comfortable with a hard copy, though, and there there are a number of highly regarded choices. Get one if you are serious about persuing the language.

A class is a blueprint for creating an object. Class to object is comparable to DNA to human.

Kuphryn

EEK, public datamembers! That's good for demonstration jsut keep in mind that it's generally not considered good practice to have your data as public.

Good descprition otherwise.

Some things I personally would have done differently (though neither way is better in all cases) is I would not have had

int numTires;
int numSteeringWheel;
int sizeEngine;
int numDoors;

as datamembers of the class

Instead, what I'd do is make an abstract base car class with pure virtual member functions for "numTires" etc. and then for different types of cars I'd just derive them from the base and then define the virtual member functions to return the proper information.

The reason one would want to do that is you can make a "corvette" class. Every time you make a corvette you don't really want to store the information of numTires, etc. with every single instance of it because it would most likely be the same. This way you cut down on the space needed for every instance. This way, you also have a separate datatype for each of your different types of cars all related through the common base.

If it becomes necissary to have the user input data about the car at runtime, you can always create a child type of the abstract car class that has variables for numTires, etc. but don't force that for all versions of cars.

I agree with Polymorphic OOP on all counts. My example was scaled down to the bare essentials of what a class is and does and how you can think of them. His description is actually the best way to do it. It takes more time and effort to incorporate all the nuances, but it makes the code easier to maintain, more robust, and better quality overall. To start out with, you may not want to "do it all", but Polymorphic OOP's description should be your eventual goal.

There is fundamentally no difference between an object and say, an integer, or a struct for instance. So there is no mysterious quality that defines an object. But more specifically, we usually say "object" in referencing a certain instance of a datatype.

So:

int number;

"number" is an object of type "int".

Typically, objects are intances of classes or structs, which are often more useful approaches to solving programming problems than simple integers or characters of course. "Object" also refers to a type of class or struct too. For instance, in C++, we have at our disposal the STL which has objects like strings, queues, maps and lists.

When you design an object, you should follow these rules:

1) less is more...don't bloat your code.
2) be specific. don't create "all-purpose" objects.
3) maintain speed. effeciency is important.
4) think generic. can I reuse this?
5) easy to use. it shouldn't be like working a rubix cube.
6) think it out. plan well.
7) debug ;).

As far as public members go, I have mixed views but generally, if it's safe to access it directly, let it be accessible. For example:

class Vehicle {
public:
int speed;
int intake_rate;
void intake(int amount){
intake_rate = amount;
speed = intake_rate * more_computations();
}
};

In the example above, the implemetor left the speed and intake_rate public, even though accessing them directly would lead to undesirable results, since additional computations were necessary.

Other than that, I think it's just a matter of style, although personally, I like using functions rather than direct access.

In the real world public datamembers would get you shot. In reality most data members are private and held in implementation classes. The real class will hold a pointer to that implementation class ( the so called pimpl idiom). This allows us to pretty much screw about with the implementation class and it not affect the clients of the real class. I would show this in code for you seb but xmas dinner is ready so must go. will do it later if polymorphic hasnt beaten me to it.

I think you need to learn C first.
Without having knowledge of programming or algorithm, it's difficult to elucidate class, overloading or template (my opinion).

pimpl idiom here #7,#24,#28.

Read the rest too. Its all good stuff.

Actually, the multithreading library I posted a while back (here) uses that very same mechanism. If you look at the class you'll notice there's a void* data member, which just happens to be a pointer to the actual object. In the code behind the class, all functions merely forwarded code to the object like this:

Code:

---

QuickThread::suspend(){
ActualClass * ac = (ActualClass *) pData;
ac->suspend();
}

---

Other than writing third-party code, there's no real justification for using a "pimple" implementation except for the non-recompilation benefits. A class is a struct, and there's no reason to completely throw direct access out the window unless you just truly don't like it, in my opinion...

thx for the help it realy helped me to understand a bit more. thx