We help IT Professionals succeed at work.

Check out our new AWS podcast with Certified Expert, Phil Phillips! Listen to "How to Execute a Seamless AWS Migration" on EE or on your favorite podcast platform. Listen Now

x

#including a file gives errors on rest of parent file

Medium Priority
218 Views
Last Modified: 2013-11-18
In MSVCPP5.0 I am porting some C code to work on winNT.  I have a vcpp class file that works fine.  I have a C file that works fine and is composed of a bunch of function prototypes with external linkage.  All of my C files I have given .cpp extensions to and am compiling without special extern "C" type modifiers.  The problem is that when I #include the (originally) C file into the class file, I get errors on compilation of the class file.  I get: "redefinition; different type modifiers" or "overloaded member function not found in 'class'" on the constructor, GetRuntimeClass, _GetBaseMessageMap, GetMessageMap, AFX_MSGMAP, AFX_MSGMAP_ENTRY, AssertValid, and Dump.  It's like #including the file makes the compiler read the rest of the parent file differently or something.

I have been able to #include this C file in other C files with no problems.  I also have been able to #include one other C file into a C++ class file with no problem.  

I also have tried putting the #include inside an extern "C" call and it makes no difference.  I seem to recall having this problem once before, on purely vcpp files.  Of course I don't recall what fixed it, but it suggests to me that it may have nothing to do with the fact that the offending file was originally C.
Comment
Watch Question

Author

Commented:
Edited text of question

Commented:
Please Try to give the full path  in the following fashion
eg.,
#include "c:\...\...\filename.c"

I hope this has to work.
Thanks and Regards - sganta

Author

Commented:
This makes no difference and also would be horrible if it did.  That's what the preprocessor paths are for.

Commented:
Or else you can include your file in the standard path directory try including
as
#include <filename.c>

Author

Commented:
Of course I AM #including the file as such:  #include <file.h>.  I meant that the preprocessor paths allow you to not need the full path such as you proposed.

Commented:
It sounds like an include file is getting included twice.  Do you use #ifdef to prevent this from happening?

Commented:
To do this use  surround the guts of the include file with the following code

#ifndef someuniquename
#define someuniquename

// include file contents

#endif

If that doesn't help, you can e-mail me the code at nietod@theshop.net.


Author

Commented:
All files use #ifndef / #define / #endif to prevent them from redefinition.

Commented:
We're kinda forced to guess at the problem.  If you would post the code or e-mail ot to us, it would help.

Commented:
have you tried putting
#pragma once
in the header file (this tells the compiler not to compile it more than once)

Author

Commented:
I've narrowed the problem down to the following file which is #included in the file that is #included in the first place.  I thought it must be interfering with standard files or definitions already used in vcpp but don't find any.  In addition to this file being #ifndef'd to protect against multiple includes, each place where it is #included is protected with:              #ifndef __ansi_HEADER__
      #include <ansi.h>
      #endif
so any suggestions are welcome.


#ifndef __ansi_HEADER__
#define __ansi_HEADER__

/*      M A C R O S
*/
/* make sure STDC is set for any of the higher settings
*/
#if defined(_XOPEN_SOURCE) || defined(_POSIX_SOURCE) || defined(_ANSI_C_SOURCE)
#ifndef __STDC__
#ifndef _AIX
#define __STDC__ 1
#endif
#endif
#endif

#ifndef __STDC__
#ifndef const
#define const
#endif
#endif

#ifndef _PARAMS
#ifdef __STDC__
#define _PARAMS( params ) params
#else
#define _PARAMS( params ) ()
#endif
#endif

/* for procedures that use variable arguments
*/
#ifdef __STDC__
#define start_vargs( varg, param )      va_start( varg, param)

#else
#define start_vargs( varg, param )      va_start( varg)
#endif


/*      T Y P E S
*/
typedef char *       STRING;
typedef const char * CONSTR;      /* a pointer to constant data */
typedef const int    CONINT;
typedef void *       VPTR;

#ifndef NULL
#define NULL 0
#endif

#endif /* __ansi_HEADER__ */

Commented:
You say you narrowed the problem down to this file.  In what way?  Do the things defined here produde duplication errors?  Does removing the file get rid of the errors (and cause others of course)?

Commented:
The #define const is verry dangerious. __STDC__ had better be defined otherwise that will be defined.  And you don't want that.  Do you know if STDC is defined?

Commented:
Seeing as the file itself is protected with a #ifndef __ansi_HEADER__  Why do you wrap the lines that include it in an if as well?  That should not be a problem, but it is unneccessary.  It could be a problem if you are mistaken about any of this, that is why I ask.

Author

Commented:
Tracing the #includes and commenting out certain things, this file caused the errors that I first mentioned.  Not including this file eliminates them (and causes others).  

Your comment about STDC being defined led me to this info:
__STDC__Indicates full conformance with the ANSI C standard. Defined as the integer constant 1 only if the /Za compiler option is given and you are not compiling C++ code; otherwise is undefined.

Since I AM compiling C++ code, this is definitely something to look at.  The file (ansi.h) was previously accounting for this at the top, but obviously needs to be reworked for win32.

As for your question about wrapping the lines that include the file with #ifndef even though the file has that, it is only because that is how it was done before and I haven't taken them out since they don't hurt.  When all else is working correctly I plan to do cleanup of that stuff.  I am putting it off until then so that I can be sure I am working with things they way they really were in the original.

Author

Commented:
It was the #define const.  Nietod, post an answer explaining what was happening with that and I'll award you 130 points.
Commented:
Unlock this solution and get a sample of our free trial.
(No credit card required)
UNLOCK SOLUTION
Unlock the solution to this question.
Thanks for using Experts Exchange.

Please provide your email to receive a sample view!

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

OR

Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.