C嵌套结构上的g ++编译错误

Question

I need the community's help with a compile error regarding C nested structs compiled with g++ .

I have the following three files:

main.cpp (for completeness; this file is not required to reproduce the compile error):

#include <iostream>
#include "ns.h"

int main( int argc, char* argv[] )
{
  someFunc();
  return 0;
}

ns.h :

#ifndef NS_H
#define NS_H

#ifdef __cplusplus
extern "C" {
#endif

void someFunc();

#ifdef __cplusplus
}
#endif

#endif // NS_H

ns.c :

#include "ns.h"

#ifdef __cplusplus
extern "C" {
#endif

#define MY_MAX (42)

typedef struct _outer
{
  int count;
  struct Inner
  {
    int count;
    void* cb;
    void* ctx [ MY_MAX ];
  } inner_[ MY_MAX ];
} Outer;

Outer g_outer[ 10 ];

#include "staticFuncs.h"

void someFunc()
{
  staticFunc();
}

#ifdef __cplusplus
}
#endif

staticFuncs.h :

#include <stdio.h>

#ifdef __cplusplus
extern "C" {
#endif

static void anotherStaticFunc()
{
  printf( "%s", __FUNCTION__ );

  struct Inner* ptr = NULL;
  ptr = &(g_outer[ 0 ].inner_[ 0 ]);
  (void)ptr;
}

static void staticFunc()
{
  printf( "%s", __FUNCTION__ );
  anotherStaticFunc();
}

#ifdef __cplusplus
}
#endif

The relevant compilation is as follows:

>g++ --version
g++ (GCC) 4.8.3 20140911 (Red Hat 4.8.3-7)
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


>g++ -g -c ns.c -o ns.o
In file included from ns.c:22:0:
staticFuncs.h: In function 'void anotherStaticFunc()':
staticFuncs.h:12:7: error: cannot convert '_outer::Inner*' to 'anotherStaticFunc()::Inner*' in assignment
   ptr = &(g_outer[ 0 ].inner_[ 0 ]);
       ^

What gives?

I'm aware that in C , nested structs are not referred to by any scoping syntax, but are referred to as though they were not nested. Ie, I'm pretty confident in that I can do struct Inner* ptr = NULL; as I did in staticFuncs.h . More important than my confidence, if I compile with cc instead of g++ , compilation goes through.

I've tried my damnedest to tell g++ that I'm compiling C , not C++ , code by throwing in extern "C" s everywhere, but it's still tripping over the scoping of Inner .

Can anyone please help identify why this compiler error arises and how I can work around it? I must use g++ to compile.

The problem is unchanged if staticFuncs.h is staticFuncs.c instead.

The problem is unchanged if the static functions are not static.

The problem is unchanged if the content of staticFuncs.h/c is embedded in ns.c instead of being #include ed.

Answer 1

While gcc will compile code as C++ if it has certain suffixes, there is no way to compile C with g++.
The only difference between gcc and g++ is that the latter always compiles C++, and that it links with the C++ libraries.

The simplest fix is

struct Inner
{
    int count;
    void* cb;
    void* ctx [ MY_MAX ];
};

typedef struct _outer
{
  int count;
  struct Inner inner_[ MY_MAX ];
} Outer;

Answer 2

The error message from the compiler is very clear.

The LHS of the assignment operator is declared as:

struct Inner* ptr = NULL;

That line equivalent to:

// Declare a struct in the function. This is different from _outer::Inner.
struct Inner;

// Declare the variable using the struct declared in the function.
struct Inner* ptr = NULL;

What you need to do is use _outer::Inner* as the type of ptr .

_outer::Inner* ptr = NULL;

Answer 3

I'm working on a project which compiles with g++ on default setup which is not ment to be changed (summarizing). And I dealed with the same problem while adding SQLite3 Amalgamation file, which is C code. In order to minimize the conflicts on Git when updating this file to merge official SQLite3 changes, you can also add the following trick, being an example of my case:

#ifdef __cplusplus
#define _ht Hash::_ht
#endif // __cplusplus

Inmediately after the struct ( Hash ) which embeds the _ht struct, which is surely used in LHS later. Of course, you have to name intermediate embedded structs if they aren't. This is elegant, and especially helpful when using thirdparty code intended to support future updates with the least amount of problems, as of what was reasoned in the first paragraph.