External classes

[Doomulation]

Now comes a problem again... this problem is pretty avoidable if headers does not include other headers, but anyway, here's the deal...

I have the class CRegistry defined in registry.h. Registry.h must include Global.h since the template functions (in registry.h) need functions defined there.
However, in turn, Global.h needs access to the CRegistry class, so it must include registry.h. There's the problem. They're trying to constantly include each other, hence the compiler is unable to find the information it needs.

Is there a way to define classes external or something? Or must it be that the registry is stored within global.h or perhaps the registry code must be commented out in global.h? Advice, please!

 

[thakis]

You have to modify one of the headers that it only requires pointers to the classes in the other header. Then, instead if #including the other header, add class prototypes ("class Bla;") at the top of the first header file. #include the other header only in the cpp.

 

[Doomulation]

Hmm, well it worked. For now at the very least. I thank ye for the advice.

 

[Doomulation]

Okay, this is just stupid. I should spend more time on making the program work rather than go about chasing issues with the compiler can't find the info in the headers... How do I go about if the class contains information that needs be used? In this case, it contains a struct a header is trying to use!

CNewPaymentDlg:aymentData to be specific. A function is taking an argument of this type. The header NewPayment.h is trying to include NewPaymentDlg.h which in turn is trying to include NewPayment.h, creating circular references. The function is declared just below, but the compiler never gets there.

 

[q1221920]

Shouldn't thakis's idea work again? With a class prototype above the class in question. If they have instances of each other, i guess there would be a prototype of the other above both. (You must have made some damn crazy code for two classes to exist within each other...) This might sound stupid, but maybe you should rework the code a little and use pointers, as it's not really normal to have the classes interacting this way.

 

[Cyberman]

Okay, this is just stupid. I should spend more time on making the program work rather than go about chasing issues with the compiler can't find the info in the headers... How do I go about if the class contains information that needs be used? In this case, it contains a struct a header is trying to use!

CNewPaymentDlg:aymentData to be specific. A function is taking an argument of this type. The header NewPayment.h is trying to include NewPaymentDlg.h which in turn is trying to include NewPayment.h, creating circular references. The function is declared just below, but the compiler never gets there.

To prevent circular madness..

#ifndef _THIS_STINKING_HEADER_FILE_H_
#define _THIS_STINKING_HEADER_FILE_H_
// include stuff here
#endif
So if it's not defined it's contents are read otherwise it's skipped.
Now you have a chicken egg problem though. Is The NewPlaymentDilog using the PaymentData structure? It should be deigned first then. The dialog then should look for that.

ALWAYS ALWAYS do what I showed you in the headers, to prevent nasty gotcha's from bad programing. This will at least keep the compilor from throwing up all over.

Cyb

 

[smcd]

You aren't putting header "blocks" to prevent infinite includes?

#ifndef ___SOME__CRAZY__IDENTIFIER__H__
#define ___SOME__CRAZY__IDENTIFIER__H_

struct Foo{
int bar;
int bas;
};

class Bar{
private:
    Foo foo;
public:
    void Bas()
    {
        foo.bar = 0;
    }
};
#endif

This "blocking" technique will keep the compiler from including more than once and might help reduce your headaches.

EDIT: bah, cyberman beat me to it, i had to go do some work before finishing the response

 

[Doomulation]

To prevent circular madness..

#ifndef _THIS_STINKING_HEADER_FILE_H_
#define _THIS_STINKING_HEADER_FILE_H_
// include stuff here
#endif
So if it's not defined it's contents are read otherwise it's skipped.
Now you have a chicken egg problem though. Is The NewPlaymentDilog using the PaymentData structure? It should be deigned first then. The dialog then should look for that.

ALWAYS ALWAYS do what I showed you in the headers, to prevent nasty gotcha's from bad programing. This will at least keep the compilor from throwing up all over.

Cyb

To that circular madness, I tend to use "#pragma once" which keeps the compiler from throwing up, or so it seems. Now it just tends to complain it can't find stuff.
PaymentData is defined IN the class NewPlaymentDialog =) That's the problem. I'm going to use a work-around for now, but still...

 

[smcd]

If that's the case you have encapsulation issues. You may need to rethink your design or introduce the data (structure) into a namespace or something so it's not 'global' but accessible.

 

[Cyberman]

To that circular madness, I tend to use "#pragma once" which keeps the compiler from throwing up, or so it seems. Now it just tends to complain it can't find stuff.
PaymentData is defined IN the class NewPlaymentDialog =) That's the problem. I'm going to use a work-around for now, but still...

Doom.. here is something to remember, #pragma's are implementation specific. IE compilor specific. IE you shouldn't use them unless you there is no choice. It's bad form and a bad habit. What I presented is the standard method used world around, for a reason. It works consistantly, you might also consider an addition to it.

#ifdef _THIS_HEADER_H_
#error Include loop problem
#else
#define _THIS_HEADER_H_
#endif

This gives you a clue you have a chicken egg situation.

I suggest not defining structures within classes, it's also bad form. Especially if these structures are going to be used in more than just that class. Even if they are only locally used. Don't do it. Bad form. Always define structures prior to use. If you are manipulating that structure it makes for a LOT of problems, just don't waste your time doing it. Doing things the hard way is a waste of time, even though it looks easy, it's not and leads to a lot of potential errors. I'm not just saying this just because it's true, I'm saying this because I've done it and stoped doing it ever again because it NEVER works out the way you expect. Always attempt to make sure everything is well defined before you start twiddling with it. Otherwise your program behavior will always be the unexpected.

Live and learn, but learn from others screw ups first

Cyb

 

[Doomulation]

Hmmmm... Of course, I need time to reflect upon this new data. There's a lot of design issues with that project, which I constantly change. I tell you, it's not easy to set up a good and basic design for something sometimes...