• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 189
  • Last Modified:

#including a file gives errors on rest of parent file

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.
0
appleby
Asked:
appleby
  • 7
  • 7
  • 2
  • +1
1 Solution
 
applebyAuthor Commented:
Edited text of question
0
 
sgantaCommented:
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
0
 
applebyAuthor Commented:
This makes no difference and also would be horrible if it did.  That's what the preprocessor paths are for.
0
VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

 
sgantaCommented:
Or else you can include your file in the standard path directory try including
as
#include <filename.c>
0
 
applebyAuthor 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.
0
 
nietodCommented:
It sounds like an include file is getting included twice.  Do you use #ifdef to prevent this from happening?
0
 
nietodCommented:
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.


0
 
applebyAuthor Commented:
All files use #ifndef / #define / #endif to prevent them from redefinition.
0
 
nietodCommented:
We're kinda forced to guess at the problem.  If you would post the code or e-mail ot to us, it would help.
0
 
dgunthorCommented:
have you tried putting
#pragma once
in the header file (this tells the compiler not to compile it more than once)
0
 
applebyAuthor 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__ */
0
 
nietodCommented:
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)?
0
 
nietodCommented:
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?
0
 
nietodCommented:
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.
0
 
applebyAuthor 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.
0
 
applebyAuthor Commented:
It was the #define const.  Nietod, post an answer explaining what was happening with that and I'll award you 130 points.
0
 
nietodCommented:
Always glad to help out little companies, like Lockheed Martin.

Unfortunately, I don't know the particulars of that it did.  I'm not sure if you are aware of this or not, but effectively it removed the keyword "const" from the source code.  This is not a good thing.  However, it doesn't actually explain the particular errors you got.  (It may have caused some other compiler errors in the future.  It certanl left room for run-time errors as well.)  
Most likely the errors you got were because the change took place partway through the code. For exampel you may have had a function like

void f(const int &i);

that was declared before the header and was defined after the header.  This would have left the const in the declaration, but would have effectively removed the const from the definition.  so the defintion became

void f( int &i)
{
}

Thus the two didn't match.  There are lots of possible variations of this type of problem.  It could be some of these.  Or it could be something totaly unreleated.  I really don't know.  I do know that the const definition was not a good thing!
0

Featured Post

Prep for the ITIL® Foundation Certification Exam

December’s Course of the Month is now available! Enroll to learn ITIL® Foundation best practices for delivering IT services effectively and efficiently.

  • 7
  • 7
  • 2
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now