Avoiding circular inclusions

[Crusher21]

Hey guys,
If I have a wndproc class and a class A where I want wndproc to inherit the members of class A, normally I would simply declare wndproc as such class wndproc : public A . However, wndproc won't know what class A is without #include-ing A.h and class A won't know what wndproc is without doing the same for wndproc.h. If I #include both of those in their respective files, I'll have a circular inclusion problem on my hands and will receive the error "A: base class undefined". If I remove the #include from wndproc, it won't know what class A is when I declare class wndproc : public A. How do I go about this problem?

[Ganado]

Try declaring

class A;

class wndproc : public A {
  // ...
    void foo(A& a) {}
};

/// ...

class A {
   // ...
};

[TwilightSpectre]

Forward declarations are your friend. I don't know how A is using wndproc (you haven't explained that — why should A know about wndproc at all?), but in most cases something like the following should work:

// A.h
class wndproc;

class A {
public:
    void foo(wndproc& proc);
    // ...
};

// wndproc.h
#include "A.h"

class wndproc : public A {
    // ...
};

Note that you cannot forward-declare for any place where the compiler needs to know anything more about the type than that it simply exists: for example as a variable, or as a base class, or a function argument. Pointers/references are fine, though.

[Crusher21]

When I leave both header files still #include-ed I still get the base class undefined error with the forward declaration. When I remove the proper header file (I decided to remove the #include declaration from wndproc), I get a weird "class A. Incompatible type is not allowed"
wndproc.h:

class A;
class wndproc : public A //error here
{
public:
	wndproc();
}

A.h:

#include "wndproc.h"
class A {
//functions
}

[MikeyBoy]

For obvious reasons, wndproc.h needs to know the full definition of A. You can't get away with forward declaration there, so windproc.h needs to include A.h.

Why does A.h need to include wndproc.h? Circular dependencies are often an indication of a problem with your design.

(I'm not the first in this thread to ask you that, but you ignored it the first time.)

[Crusher21]

My bad. If A.h doesn't include wndproc.h, I can't create an object of class wndproc and use the object to call its functions.

[MikeyBoy]

Why does the code inside A.h need to create wndproc objects?

[Crusher21]

The objects will be created in A.cpp. A.cpp needs to be able to create an object of wndproc so that it can perform calculations on a member variable of A using a function defined in wndproc.h. Is there a way to do this without doing an #include of wndproc.h inside A.h?

[MikeyBoy]

So why does A.h need to include wndproc.h? Why can't A.cpp include it?

Having said that, there's still something fishy design-wise about A being a base class of wndproc, but also needing to know about wndproc.

Are you sure you're doing the right thing by having wndproc inherit from A? Do you understand properly what kind of relationship inheritence models?

[Crusher21]

Ohhh that was a misunderstanding that I had. For some reason I thought the best practice was to do the #include's in your header file, I didn't even think about putting it in the .cpp. It now compiles just fine.
And I agree, there's a lot that I still have to learn about best practices when designing programs. I assume the best way to design classes is to make them independent from each other and to simply pass necessary variables into the constructors.
I'm still pretty new to dealing with classes (I've been avoiding them for awhile) so I'm open to all ears. I want to learn the proper ways of using them. I want wndproc to inherit from A because I want it to be able to see, use, and modify the member variables of A. Afterwards, A will continue to use the modified member variables for the rest of the program. Does this sound like an ideal case for using inheritance to you?
I thought inheritance just meant that, for example, wndproc would inherit all of A's members.

[MikeyBoy]

I want wndproc to inherit from A because I want it to be able to see, use, and modify the member variables of A.

OK, that is absolutely not a reason to use inheritance. Inheritance is not there as a convenient shortcut around the principles of encapsulation.

Put simply, inheritance models an "is-a" relationship - that is, it would be relevant if wndproc is a type of A. The parent class defines data and behaviour that is common to all objects of that type, and, crucially, the interface that all objects of that type will have. Specialised behaviour and data goes into the subclasses.

For example, if you were writing a program that dealt with vehicles, you might have a Vehicle base class that includes things common to all vehicles, including a common interface. If you then needed cars to behave differently from aeroplanes, you might then have Car and Plane classes, each of which would define the behaviour specific to those types, while conforming to the Vehicle interface, and inheriting common behaviour from Vehicle.

There's a lot more that could be said about inheritance. I suspect this would be a good point to find a tutorial on object-oriented design, so that you know what classes are actually for, and how to use features like inheritance.

[Crusher21]

I understand. I'm definitely doing it wrong then. What would be the proper way to deal with this situation?

[MikeyBoy]

Ideally, the proper way to deal with it would be to think rigorously about what kind of services your A class is meant to provide to the code that will use it, and then design it to have an interface that will enable it to do so. If, for example, you need it to provide certain things to wndproc, then give it the interface to do that.

That might mean get/set methods, if that's the right interface for it to have, or it might mean something more tightly constrained.

[Crusher21]

I thought get/set methods were only useful when dealing with private variables?
Class A is meant to be most of the work. The only thing class wndproc is responsible for is creating a friendly user interface for the user to make a selection and then storing that selection in a vector. After that, class A takes over and uses that information.
I suppose I could simply pass the variables over in the constructor. I could simply pass them by reference couldn't I? That way, the changes are reflected in A. Correct me if I'm wrong.

[MikeyBoy]

I thought get/set methods were only useful when dealing with private variables?

What sort of variables are you talking about wndproc having access to?

In any case, I said "That might mean get/set methods, if that's the right interface for it to have". If it's not the right interface, then don't.

I suppose I could simply pass the variables over in the constructor. I could simply pass them by reference couldn't I? That way, the changes are reflected in A.

Passing variables into a function by reference, means that if the function changes them, then that change is reflected in the calling code.

It sounds like what you might be thinking of is to store them by reference, as long as you understand properly how references work. But what's wrong with simply providing interface methods to allow A to provide to windproc the services that it needs access to?

[Crusher21]

wndproc will have access to two booleans, a vector<int>, and an int.
I don't exactly know what you mean by an "interface". Could you elaborate?

[MikeyBoy]

wndproc will have access to two booleans, a vector<int>, and an int.

But are they public, protected, or private?

I don't exactly know what you mean by an "interface". Could you elaborate?

Briefly, the public part of a class.

Again, this is really where you would do yourself a lot of favours by reading some introductory material on Object-Oriented Programming.

[Crusher21]

I apologize for the delay. They are public. I'll read up on that material. Thank you for all your help

[MikeyBoy]

Making data members public isn't always the wrong thing to do, but it's something to be considered very carefully. The whole point of encapsulation is separate the implementation of a class from its interface, and to hide the implementation from calling code. The choice of what data members a class should have is - usually - an implementation detail, and hence data members are usually best made private.

There are times when it's right to make data members part of the public interface, but that's something to carefully consider, rather than doing it Just Because.

Having said that:

Once you've read a bit about OOD, and considered the design of your class's interface, then if you decide that making those data members public is still the right thing to do, then - why do you need to worry about inheritance at all here?