[GCC] C/C++ Struct Ambiguity

Question

2.00/5 (2 votes)

See more:

I'm working on a game engine written in C with C++ bindings and have run into slight snag with ambiguity. Here's a simplified version of the problematic part of my header:

C++

/* C Code """""""""""""""""""""""""""""""""""""""""" */
extern "C"
{

struct Engine_Module
  {
    char *name;
  };

typedef struct Module Module;


extern int Engine_Module_Begin(Engine_Module *this);



}
/* CPP Code """""""""""""""""""""""""""""""""""""""""" */
namespace Engine
{
class Module
  {
    char *name;


    public: int Begin();
  }:
}

When the user is writing the game in C, the main source would be

C++

struct Application
  {
    Engine_Module base;
  };

typedef struct Application Application;


int Application_Begin(Application *this)
  {
    printf("Hello World\n");
  }


int main(int argc, char *argv[])
  {
    Application application;
    return Application_Begin(&application);
  }

When the user is writing the game in C++, the main source would be

C++

class Application : public Engine::Module
  {
    public: int Begin()
      {
        printf("Hello World\n");
      }
  };


int main(int argc, char *argv[])
  {
    Application application;
    return application.Begin();
  };

Both work fine when compiled with their respective file types, but if I attempt to use the Engine_Module struct from C++ I get an ambiguity error saying there are 2 definitions for the Engine_Module struct. I'm assuming this is because GCC's C++ classes derive from structs in some way. It's not a major issue (if anything, it even helps to enforce users of the engine I'm writing to only use C in C files and C++ in C++ files), but I'm wondering if there is a alternative to this aside from branching to a C function.

Any ideas?

Posted 20-Nov-13 3:46am

Ghosuwa Wogomon

Add a Solution

Comments

Sergey Alexandrovich Kryukov 20-Nov-13 11:42am

Certainly not. Classes and structs are essentially the same in C++. Deriving a class from some struct could not possibly create ambiguity, they would remain different types. The real problem is that Engine_Module name is really used as a type name in two different type declarations. Please find it out. The information you provided is not enough.
—SA

Ghosuwa Wogomon 20-Nov-13 12:16pm

I didn't say that the the Engine::Module class derived from Engine_Module, I was saying that GCC seems to be creating a second Engine_Module struct definition for the Engine::Module class that throws an ambiguity error if I try to use struct Engine_Module in C++ code. If you try to initialize the application module with the C code and compile with g++, it states there are 3 instances called

typedef Engine_Module
Engine_Module
Engine_Module

Creating an instance like "struct Engine_Module module;" should fix the problem, but it doesn't. So I can only assume that both definitions are structs.

Sergey Alexandrovich Kryukov 20-Nov-13 12:23pm

I also did not say that. No, GCC does not create anything without your code, no second definitions. I tell you, check up all your code...
—SA

Ghosuwa Wogomon 20-Nov-13 12:30pm

Why do you assume I haven't? There is only 1 definition of the Engine_Module struct and it's typedef in my code. When compiled as C code there are no problems whatsoever. When compiled as C++ code, there an additional definition. The only thing defined in the C++ code is the Engine namespace and the Module class.

Since using "struct Engine_Module" specifically does not solve the issue, then both definitions are structs, which means GCC is creating a second Engine_Module struct under the table without my code.

Sergey Alexandrovich Kryukov 20-Nov-13 13:21pm

Only because you blame GCC in something it cannot do...
—SA

Stefan_Lang 22-Nov-13 4:03am

See my response. The typedef is likely wrong (creating a second defintion by the same name), although you haven't shown it in the code you posted above. Eliminate that typedef - it's nonsense anyway.

Ghosuwa Wogomon 23-Nov-13 15:04pm

Like I said, I defined 2 definitions; a typedef and a struct. GCC is saying there's <3>. And no, it's not nonsense. It's the standard way of defining a new struct type that isn't anonymous. In C, a definition like:

struct MyType
{
};

has to be declared

struct MyType mt;

In C++, they remove this requirement so you can just type

MyType mt;

But for C you have to declare a type definition that overrides it. I prefer to declare structures this way because they're easier to document, I like GNU style block indentation, and I can do things you can't do with an anonymous definition like:

struct MyType
{
struct MyType *parent;
};

Richard MacCutchan 20-Nov-13 14:39pm


struct Engine_Module
  {
    char *name;
  };
 
typedef struct Module Module;

Are you sure that typedef is correct?

Sergey Alexandrovich Kryukov 20-Nov-13 16:31pm

Ha-ha, good point. :-)
—SA

CPallini 22-Nov-13 4:01am

My virtual 5.

Ghosuwa Wogomon 23-Nov-13 14:59pm

I probably mistyped it when I was writing the brief version for the question, but it's actually

typedef struct Engine_Module Engine_Module;

Philippe Mori 20-Nov-13 18:36pm

Also you have to be careful that any declaration are effectively Inside extern "C" as otherwise I think they would be considered different. Assuming whole code is above, it does not seems to be the case.

Ghosuwa Wogomon 23-Nov-13 15:28pm

I would like to know why I as the person who asked this question cannot respond to or decline the solution of the person who posted the solution to my problem. Their answer is 100% incorrect and the user obviously has no experience with C.

typedef's are required for structs in C. A typedef with the same name as a type will not cause errors in C or C++, I have used them for years and they were designed specifically for that purpose until C++ made the struct and enum keywords optional for declarations. The this keyword is only reserved for functions that use the thiscall calling convention which is in fact nothing more than passing a hidden argument called 'this' on the stack that points to the class. Replicating C++ class functionality was the entire idea.

Richard MacCutchan 24-Nov-13 3:25am

You are free to add any comments by clicking the Have a Question or Comment? link below the solution.

Stefan_Lang 25-Nov-13 5:39am

I may have been wrong about the typedef, please note that I later added a P.S.: statement to that effect! Last time I've actually written C code rather than C++ was 25 years ago, so I'm never quite sure what changes made it into C as well, but I've always thought that trivial and sensical changes such as not needing that typedef would of course be included in C. Oh well, ...

Anyway, since your problem was a C++ compiler error, I was basing my suggestions on C++ code. If those typedefs are not part of the C++ code, then ignore those comments in my solution. Your posting suggests as much, but since there is nothing else in the code you posted that may be the cause of such an error I decided to mention it anyway.

However, in that case the problem is in the code that you did _not_ post! Since the compiler complains about a duplicate definition, it must have somehow read and interpreted two definitions: either it picked up stuff from your C only code that it shouldn't include (but wasn't correctly marked), or you messed up your includes, or you messed up your variable and type naming: maybe you mistyped a lowercase for an uppercase character or vice versa? To be sure, please copy&paste the actual code segments - retyping always hides typos and introduces new ones, so we have no chance to find the actual problem!

Stefan_Lang 25-Nov-13 5:48am

Please copy&paste the relevant code segments, and the same for the compiler error message! There are typos in the code you retyped that we know of, and there may be more that we do not! Also the compiler message may provide more useful info that you chose to omit. moreover, the posted C++ code does not even contain the duplicate type name even once - so that's probably just another typo!

We can't guess your typos - please copy&paste!

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Stefan_Lang · Accepted Answer · 2013-11-21T21:44:00

typedef struct Module Module;
typedef struct Application Application;

That's complete nonsense (and may in fact lead to warnings or errors). C++ (and AFAIK ANSI C as well) already let you use the struct name without having to precede it with the struct qualifier!

On a sidenote: using a self-defined type name that is identical to the name of a previously defined type is at the very least confusing, and AFAIK an error, too: whenever the conpiler finds the name Application it won't know whether you mean your typedef'd name or the struct by that name! You can define two variables of the same name within the same scope legally (to the effect that the variable defined last will hide access to the first), but you can not define types of the same name. This may in fact be the cause of your problem.

extern int Engine_Module_Begin(Engine_Module *this);

Another piece of nonsense: this has no meaning in C, but may lead to confusion for those who know C++. In fact, if you try to compile that in C++ your compiler will likely complain, because this is a reserved keyword!

As for your problem, the code you've shown doesn't even use Engine_Module (it uses Engine::Module instead), so the problem must be in other parts of your code.

More generally, I advise you to drop the dual C++/C program structure idea. If you want to make your engine accessible to both C and C++ programmers then you should just write it in C++ and then - when it's done - provide C function wrappers that hide the C++-specific interface. You're needlessly hamstringing your development by always trying to fit your API to both at once, and that simply will not work!

P.S.:
After checking the references I've found that structs in ANSI C still require the struct keyword to be used, so some sort of typedef is still necessary. However, in C++ it is not necessary, and reusing the struct name as typedef name may in fact be the casue of errors. So if the same code is compiled for both C and C++ you need to make sure those typedefs are excluded for C++ compilation!