Easy question for you

[SlashOwnsU]

hi...I used to program in java - things were so nice with the packaging and all

now I'm new to C++ and having just a small problem with the include concept...

I'll make a classical example - let's say I have a Wheel class (in Wheel.h) and a Car class (Car.h)
I want the cars to have an array of wheels, thus I include Wheel.h in it...but let's say I want the wheel to know what car it's on - it has a Car ownedBy attribute...I'll have to include Car.h...mutual visibility between classes

what happens to the compiler is this:
- include Car.h from another file
- include Wheel.h from the Car.h header
- tries to create a Car instance, but can't because Car is undefined yet...it'll be defined when the compiler is done with Wheel.h

I tried to add
#ifndef WHEEL_H
#define WHEEL_H
...
#endif
in both files but it doesn't work

I don't know if you get the point, but basicly I want two classes from two different files to see eachother while avoiding multiple includes

 

[xwb]

Use a forward declaration in the header files. If you use a pointer in the class/structure declaration, the definition doesn't have to exist until you start accessing the members of the structure.

Something like

wheel.h
#ifndef Wheel_h
#define Wheel_h
class Car;
class Wheel
{
...
   Car* m_car;
};
#endif

car.h
#ifndef Car_h
#define Car_h
class Wheel;
class Car
{
...
   Wheel* m_wheel;
};

As a Java programmer, you're also probably not used to the concept of tidying up - don't forget to delete the stuff once you've finished with it. There is no automatic garbage collection unless you are using M$ really painful extension to C++ called managed C++. It is easy to forget when switching from C# or Java to C++.

 

[PerFnurt]

>There is no automatic garbage collection unless you are using M$ really painful extension to C++ called managed C++.

Or you can use std::auto_ptr or the STL collections - they clean it up for you nicely.

/Per
[sub]
www.perfnurt.se[/sub]

 

[Skute]

Or you could design your classes better so that child objects dont know anything about their parent objects.

Then you could have a function on the car which tries to identify a particular wheel.

If youve got a car handler object, which contains all instances of car, then the handler can loop through each car examining the array of wheels. When it finds the wheel in question it can return the car pointer.

Easy, it adds a little extra bit of complexity, but i think its a neater design. (Especially if for instance a wheel gets moved from one car to another, it means youve got to update the array of wheels on the car, and for each wheel you then have to update the ownedBy attribute)

Skute

"There are 10 types of people in this World, those that understand binary, and those that don't!"

 

[PerFnurt]

And if, conceptually, a wheel always is owned by a car it could hold a Car& (set in contructor) rather than a Car*.

Skute: Good idea - though I generally try to avoid classes like ....Mgr, ....Handler


/Per
[sub]
www.perfnurt.se[/sub]

 

[SlashOwnsU]

IMHO I really don't know how going through a list of cars to search for a specific wheel just to find its owner can be better than just telling the wheel who its owner is...
let's say I have a linked list of 3221 eighteen wheels cars - I'm not going through it all just to find the wheel that matches the one I'm looking for
to me, just specifying a variable is just less work for the CPU and it's simpler - ok it adds coupling, but it's basic-logical coupling


anyway, that trivial example of mine doesn't concern what I'm programming, but xwb's solution works great...
thanks a lot

 

[PerFnurt]

>IMHO I really don't know how going through a list of cars to search for a specific wheel just to find its owner can be better than just telling the wheel who its owner is

It's about reducing redundancy, what in database terms would be called normalization.
But it comes at a cost as you mention.

>ok it adds coupling, but it's basic-logical coupling

You seem to know what youre doing, fine. But just be aware that with redundancy comes some overhead as well.

/Per
[sub]
www.perfnurt.se[/sub]

 

[Skute]

As i mentioned, you need to update 2 locations if you ever change a wheel on a car, compared to just updating 1 location with my method. Which means you need to be extremely careful to make sure that both locations match up, else your objects will become out of sync.

Cheers,

Skute

"There are 10 types of people in this World, those that understand binary, and those that don't!"