Avoiding class reference (pointer) crossing

This one should be simple and reminds me of the cross referencing problem notorious in the Assembler world. I'd like to find a more elegant solution to the problem, which as luck would have it I've seldom come across.

Dialog_A uses functions and variables in Dialog_B and Dialog_B uses functions in Dialog_A. If I do the following, for maximum scope, the compiler screams:

#include "Dialog_B.h"
Dialog_B pB;

#include "Dialog_A.h"
Dialog_A pA;

Compile one or the other cpp and the compiler will complain.

I hope you have some good suggestions on avoiding what should be a simple problem.

Who is Participating?

Improve company productivity with a Business Account.Sign Up

BelgaratConnect With a Mentor Commented:
The standard workaround is this:

#ifndef __dialog_a_h__
#define __dialog_a_h__

#include "dialog_b.h"
<everything you want>


#ifndef __dialog_b_h__
#define __dialog_b_h__

#include "dialog_a.h"


This way contents of either of the headers will not be #included more than once
RJVAuthor Commented:

That's what I would have imagined, but no, that does not solve the problem. In fact, Visual C++ 5.0 includes this type of definition in every single header file, together with the product serial number.


What error messages are you receiving from the compiler ?
Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

RJVAuthor Commented:
These three:

Dialog_B.h(108) : error C2501: 'Dialog_B' : missing decl-specifiers
Dialog_B.h(108) : error C2146: syntax error : missing ';' before identifier 'pA'
Dialog_B.h(108) : error C2501: 'pA' : missing decl-specifiers

Comment out 'pA' in Dialog_B.h and all's okay.


put a forward declaration
    class Dialog_A;
before Dialog_B and vice versa. Move the #include-s to the cpp files.
RJVAuthor Commented:
Have you tried that? You should get this error:

   error C2079: 'pA' uses undefined class 'Dialog_A'

This from compiling Dialog_B and leaving 'Dialog_A pA;' in the header file. I had suspected that as the necessary #include was removed from the header file.

Note that when I posted the question I had solved the problem by leaving the #include in the header file of Dialog_A; namely, unchanged from the first example I posted here. I removed 'Dialog_A pA' and the #include for Dialog_A from Dialog_B's header file and placed both in the cpp file. I put 'Dialog_A pA' outside the class (i.e. up top), thereby making that a global variable. I don't think this is the most elegant solution, though, which is why I came here.


Oh, I didn't read carefully - I assumed pA was a *pointer* to a Dialog_A. Ofcourse there is no way for a Dialog_B a to contain an actual Dialog_A and vice versa: Just imagine calculating the size of such an object:
sizeof (Dialog_A) = x + sizeof(Dialog_B) and sizeof (Dialog_B) = x + sizeof(Dialog_A) !

You should make each class hold a *poinetr* to the other class, not an actual object.

RJVAuthor Commented:
I'm glad you grasped it! BTW, is there any difference in the demand on memory from the pointer to holding the object? I ask as most of the very powerful MFC toolkits don't use pointers, but the object method.


A pointer has the same size, regardless of what it is pointing too (OK, there are exceptions, I know). So, if you use a pointer, you get
sizeof (Dialog_A) = x + sizeof(pointer) and sizeof (Dialog_B) = y + sizeof(pointer)
no infinity there.

> I ask as most of the very powerful MFC toolkits don't use pointers

Huh? You use value containment when appropriate, and pointer when appropriate. There is no rule that sais "don't use pointers". For example, if you use value containment, then the lifetime of the contained object is limited by the liftime of it's container. If this is not what you want, then value containment will be wrong.

Maybe you should state the problem you are trying to solve (ie, *why* do you need Dialog_A in Dialog_B and vice versa) and then one of the experts will be able to offer better advice.
RJVAuthor Commented:
You can nearly always use one or the other, through pointers are generally obtainable at any time. However, the scope or lifetime of the pointer is just as limited as you desire, as with object referencing.

The why one needs to access the data of the other is due to:

   1. Scope or lifetime of the object
   2. Both are dialogs, as indicated. The child dialog needs
      data of its parent. The parent simply must have access
      to the child. The scope or lifetime must include all
      functions of the parent.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.