Thread: need some help (classes)

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

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.

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...