C / C++ / MFC

22-Sep-03 17:23

I have laboriously coded around this little problem for years and I know that the solution is quite simple. But I am resistant to change and hate having to delve into documentation.

I am getting that "class already defined" error message when I include the same header file in more than 1 source file.

Here is what is happening:

ClassX - a user defined class
Window1 - the apps main window
Window2 - a modal dialog box invoked from Window1

Window1 has an instance of ClassX and so has "#include ClassX.h" in its header file (and won't compile without it of course)

Window2 has an instance of ClassX and so needs to "#include ClassX.h" in its header file

But it can't because it throws that error "C2011: 'ClassX' : 'class' type redefinition" error

Why is it that you can include headers like "afxdb.h" in a zillion files and not get this error?

If the compiler knows that the class is already defined, then why does it need the header file in both places?

Nish Nishant22-Sep-03 17:39

Nish Nishant

22-Sep-03 17:39

Terry O`Nolley wrote:
Window1 has an instance of ClassX and so has "#include ClassX.h" in its header file (and won't compile without it of course)

Window2 has an instance of ClassX and so needs to "#include ClassX.h" in its header file

Declare the ClassX header file in Window1's and Window2's cpp files and not in the h files. make sure you include this header *before* you include te header file for Window1/Window2. So Window1.cpp would ne :-

include classx header
include window2 header
include window1 header
...

and window2.cpp wopuld be :-

include classx header
include window2 header
...

Regards
Nish

Extending MFC Applications with the .NET Framework [NW] (coming soon...)
Summer Love and Some more Cricket [NW] (My first novel)
Shog's review of SLASMC [NW]
Come with me if you want to live

Terry O'Nolley22-Sep-03 17:54

22-Sep-03 17:54

Thanks Nish.

This brings me to a problem though - since Window2 needs a member variable of ClassX (because that member variable will be filled in by Window1 after instantiating Window2 but before calling DoModal()) doesn't the #include ClassX.h need to go before the class definition for Window2?

Nish Nishant22-Sep-03 18:19

Nish Nishant

22-Sep-03 18:19

Hey Terry

While Mike's ifdef solution probably solved the issue, by including header files in the right order in cpp files, the issue can be solved without using preprocessor directives (which makes the code easy to port assuming you wanna port it of course)

Anyway, glad you got it working right Smile | :)

Nish

Extending MFC Applications with the .NET Framework [NW] (coming soon...)
Summer Love and Some more Cricket [NW] (My first novel)
Shog's review of SLASMC [NW]
Come with me if you want to live

Terry O'Nolley22-Sep-03 19:15

22-Sep-03 19:15

How would you resolve the issue I was having without using preprocessor directives?

I seemed to have been caught in a Catch-22.

WHen I followed your example, it didn't give an error relating to duplicate class definitions, but I got errors for an undefined keyword (ClassX) because the ClassX header wasn't included until after I tried to define an object of ClassX.

Nish Nishant22-Sep-03 19:17

Nish Nishant

22-Sep-03 19:17

Terry O`Nolley wrote:
WHen I followed your example, it didn't give an error relating to duplicate class definitions, but I got errors for an undefined keyword (ClassX) because the ClassX header wasn't included until after I tried to define an object of ClassX

In any CPP file, you *must* include the ClassX header file *before* you include any other header file that might declare a ClassX member.

Nish

Extending MFC Applications with the .NET Framework [NW] (coming soon...)
Summer Love and Some more Cricket [NW] (My first novel)
Shog's review of SLASMC [NW]
Come with me if you want to live

Terry O'Nolley23-Sep-03 7:53

23-Sep-03 7:53

I know this. But your first suggestion told me to include the header file in the .cppp file for Window 2 to avoid the "duplicate class name" error. I couldn't do this, because there was a member variable of tyoe ClassX in Window2.

When presented with the preprocessor directives, I implemented them and it fixed the problem but you said this was not a preferred technique because of portability concerns.

How would you do this without preprocessor directives?

ClassX

Window1 : has a member var of ClassX so needs #include ClassX.h
Window2 : has a member var of ClassX so needs #include ClassX.h

if I include them both where you have agreed they need to be ie before the ClassX object is defined I get a compiler error of a duplicate class name.

If I include them where you first told me (in the CPP file before the window header) I get an undefined name error.

Using preprocessor directives allowed me to successfully do what I needed but you said it was a poor solution.

I would like to know the correct solution.

Michael Dunn22-Sep-03 17:58

Michael Dunn

22-Sep-03 17:58

You need include guards in your header files:

// In ClassX.h
 
#ifndef CLASSX_H_INCLUDED
#define CLASSX_H_INCLUDED
 
// rest of header here...
 
#endif // ndef CLASSX_H_INCLUDED

There is also #pragma once but I prefer the above way since you can test for whether ClassX.h has been included with #ifdef CLASSX_H_INCLUDED

--Mike--
Ericahist | Homepage | RightClick-Encrypt | 1ClickPicGrabber
CP SearchBar v2.0.2 released

Terry O'Nolley22-Sep-03 18:15

22-Sep-03 18:15

Thanks Mike - that did the trick.

I had used those a while back without remembering why I used them Smile | :)

And I never noticed when I stopped using them.

I guess it took a big screeching halt to make me remember to always use them.

Rick York22-Sep-03 18:26

Rick York

22-Sep-03 18:26

I take things a bit farther. Here is what I do :

#ifndef _HEADER_H
#define _HEADER_H
#else
#error repeated include of this file
#endif

then if this header must be included in another header file (nested) I do this -

#ifndef _HEADER_H
#include header.h
#endif

I went through and converted a rather large project to this scheme and my compile times decreased considerably. If you use a standard macro naming mechanism (_HEADER_H for me) then this is quite easy to use.

The Ten Commandments For C Programmers

Alvaro Mendez23-Sep-03 4:22

Alvaro Mendez

23-Sep-03 4:22

Rick York wrote:
#ifndef _HEADER_H
#include header.h
#endif

I used this technique for a while and then I realized that the increased code clutter (three lines/include vs just one) wasn't worth the extra milliseconds saved per compiled unit. Instead, I made sure to use a precompiled header which really sped things up.

Regards,
Alvaro

Hey! It compiles! Ship it.

Rick York24-Sep-03 14:09

Rick York

24-Sep-03 14:09

I know what you mean but I only do this when nesting include files - including one header in another. This keeps the headers safe. I don't do this in standard code as I'll see the error soon enough.

Yes, in most projects, the savings amount to milliseconds but in large scale projects this can add up significantly. I have been forced to use a library that is absolutely atrocious in this respect.

The Ten Commandments For C Programmers

John M. Drescher22-Sep-03 18:02

John M. Drescher

22-Sep-03 18:02

Terry O`Nolley wrote:
Why is it that you can include headers like "afxdb.h" in a zillion files and not get this error?
You can use either an ifdef to include the cpp file only once

#if !defined(_MYCPPFILENAME_)
// make sure _MYCPPFILENAME_ is not defined in any of your headers or cpp files
#define _MYCPPFILENAME_

// Put your class def here.

#endif //def _MYCPPFILENAME_

Or you can use this as the first statement in your header file

#pragma once

There is a macro in vc6 that does this for you. Click Tools then customize then addins and macro files and then make sure SAMPLE is checked. Then open your header file and click tools then macros select sample and then select OneTimeInclude and click run.

John

Terry O'Nolley22-Sep-03 18:20

22-Sep-03 18:20

I have done what you suggested and it is perfect.
This will save me a lot of time. Many thanks!

John M. Drescher22-Sep-03 18:30

John M. Drescher

22-Sep-03 18:30

I use the macro for this all the time because I prefer the #ifdef solution and it saves me a a few steps...

John

Callbacks

halblonious22-Sep-03 16:50

22-Sep-03 16:50

In a function, I create a font chooer dialog for my user, for which I'm trying to add a callback function, like so:

//create the pointer
LPCFHOOKPROC FontHook;

//create the font chooser dialog
CFontDialog dlg(&LogFont,CF_ENABLEHOOK|CF_EFFECTS|CF_BOTH|CF_NOVECTORFONTS|CF_NOSCRIPTSEL|CF_INITTOLOGFONTSTRUCT,NULL,NULL);

//tell it to hook to the function
dlg.m_cf.lpfnHook = FontHook;

//display the font dialog
if(dlg.DoModal() == IDOK)
{
//blah blah
}

Then, elsewhere in the view I added the actual callback function, like so:

UINT CALLBACK FontHook(HWND hdlg,UINT uiMsg,WPARAM wParam,LPARAM lParam)
{
//blah blah
return TRUE;
}

It compiles fine, but when I try to use the font dialog is gives me an application error:

"The instruction at '0xcccccccc' referenced memory at '0xcccccccc'. The memory could not be 'read'."

It desplays this three times, before quitting out. I figured out it's on the .DoModal line where it's having the issue, I think. It gives me this error when debugging:

"Unhandled exception in Application.exe: 0xC0000005: Access violation."

Can anyone please tell me what I'm doing wrong or forgetting to do?

halblonious

Phil Speller22-Sep-03 22:14

Phil Speller

22-Sep-03 22:14

The problem is to do with your FontHook pointer. To get this working you need to remove the following from your code:

<br />
  //create the pointer<br />
  LPCFHOOKPROC FontHook;<br />

Then ensure that you have a prototype for the callback fn somewhere before where you create your dialog. Prototype will look something like:

<br />
  UINT CALLBACK FontHook( HWND, UINT, WPARAM, LPARAM );<br />

What you are doing wrong is creating an uninitialised local pointer in your dialog creation fn and you specify this pointer as the address of the callback fn. In debug mode, items such as un-initialised pointers always get set to 0xCCCCCCCC so that it's easy to recognise them as such.

Phil

halblonious23-Sep-03 11:35

23-Sep-03 11:35

Thank you very much, that seemed to work. Now, I'm off to figure out how to make do what I want...

halblonious

Member 42425922-Sep-03 22:14

Member 424259

22-Sep-03 22:14

Try this instead of ur function write

UINT_PTR CALLBACK CFHookProc(
HWND hdlg, // handle to dialog box
UINT uiMsg, // message identifier
WPARAM wParam, // message parameter
LPARAM lParam // message parameter
);

and then try out if not write back

Thanx
TAKE CARE

halblonious23-Sep-03 11:37

23-Sep-03 11:37

I've got it working now. Thank you for your comment.

halblonious

David Crow23-Sep-03 3:07

David Crow

23-Sep-03 3:07

In addition to what Phil has already pointed out, by using CF_BOTH, I believe that the hDC member of your LOGFONT structure must also be initialized. Are the other members properly initialized?

Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?

halblonious23-Sep-03 11:36