Ok I've been coding in C++ for a long time. My project is getting rather large and not-withstanding the MSVC crash every 50 builds it is going rather well.

However the include stuff is a gigantic mess. So I went to edit some of it and now I have well over 1250 errors and no way to fix any of it.

In a C++ program correct me if I'm wrong but all headers needed for the CPP file should be in the respective header.

But in MFC the frieking includes are in the damned CPP file? Why?
And now I have a dialog (CLayersDlg.h) that needs to include CMainFrm.h, but the CMainFrm.h must also include CLayersDlg.h.
But when I do this, the stupid compiler tells me that basically this is undefined:

Code:

#include "CLayersDlg.h"
...
CLayersDlg LayersDlg;

The solution in C++ is to use a #ifndef #define #endif block. This will prevent multiple includes but will solve the issue when you have a cyclical include. For some reason MFC is not doing this. Even though it defines some god awful #if (!defined AFX_SOME_BIG_NUMBER_BLAH_BLAH_BLAH) it is still using the same principle.

I don't want a pointer to the actual MFC class, but I want a pointer to my derived class which is why I need to include CMainFrm.h

All this is really making me...um...mad.

And since my project is over 4K lines......I'm really mad now that I tried to add one thing and the whole program came crashing to its knees. Same issue. Included a header file so I could use it's class data type in a class header file and it said the damned thing was undefined. Unbelievable. I know what it is doing but I don't know why. It is saying that it is undefined because even though I put #include<some_header>, some_header has already been included and so it doesn't include it. But if some_header has already been defined then some_header inside of <some_header.h> should also be already defined. So doing this should work:

SomeObject.h

Code:

#ifndef SOMEOBJECT
#define SOMEOBJECT

class SomeObject
{
};

#endif

SomeClass.h

Code:

#ifndef SOMECLASS
#define SOMECLASS

#include "SomeObject.h"

class SomeClass
{
SomeObject Object;
...
};

This should work. But this is exactly what I'm doing with LayersDlg and it is not working.

10-29-2005

VirtualAce

I fixed it by just dumping the pre-compiled headers. Somehow the PCH file got messed up and was causing lots of issues. Bad MS, bad.

10-29-2005

SMurf

I don't see why precompiled headers are all that necessary to be enabled by default, we've left the days of 50 MHz 486's behind, most compilation jobs take a few minutes at best and all PCH does is shave a few seconds off. It's not like I've ever heard of programmers being tied to the clock like call centre peeps ("Compile this in 35 seconds or you're fired!")... :rolleyes:

But yes Bubba, if you use MFC in a big program you are gonna have to deal with little problems like that. Call it a learning experience. ;)

10-29-2005

VirtualAce

Oh and any suggestions on serialization? My editor saves and loads tile maps along with tile resource files (former BMPs, header removed and replaced with my own pertinent info, and RLE compressed RGB data). The streaming method for MFC doesn't really fit my needs so I wrote my own save file functions. Bad practice? Should I always use Serialize()?

10-31-2005

Ancient Dragon

you only really need to use serialize() if you want to serialize MFC objects. Otherwise, if you are just writing/reading your own non-MFC objects you can do your own thing outsize CArchive and CFile.

Quote:

In a C++ program correct me if I'm wrong but all headers needed for the CPP file should be in the respective header.

It's a matter of programming style, I've seen it done both ways by various programmers. and VC++ 6.0/7.0 application wizards do it both ways too -- stdafx.h contains all commonly used header files, which *.cpp files contain includes for the files that are not so common throught the program. And you can feel free to add additional stuff to stdafx.h. Just make sure you do a full rebuild so that the precompiled headers get rebuilt.

Precompiled headers are not unique to Microsoft compilers. The last time I was on GNU.org there was some comments about g++ also using them. I don't know how wide-spread that idea has become.