g++ doesn't support "C-struct member initialization" extension of gcc?

ta0kira · 04-12-2008, 02:21 PM

Take the following code:

Code:

static struct
{
    int value;
} local = { .value = 0 };

This compiles with gcc but not with g++, even with extern "C". I realize that this isn't part of a language standard, but I want consistency between my C and C++ files. Additionally, I want to be explicit with member initialization to reduce the possibility of bugs with large structures. The most critical places I need this are with POSIX structures that aren't necessarily ordered the same way across different OSes (perfect example: struct flock on Linux vs. FreeBSD.)

I can't use normal C++ structures in most places I'm using this. My project's API is in C and the C-structs are returned or fed to hook functions, but are assembled by C++ code internally.
ta0kira

dmail · 04-12-2008, 02:38 PM

Quote:

I can't use normal C++ structures in most places I'm using this...

So I take it that all the structs are POD? by the way value will be default initialised to zero and this is not a gcc extension it is part of the C language.

ta0kira · 04-12-2008, 03:19 PM

Quote:

Originally Posted by dmail

So I take it that all the structs are POD? by the way value will be default initialised to zero and this is not a gcc extension it is part of the C language.

Yes, they're all pointers and integers for the most part. If it's part of C, why won't g++ compile it even when it's in a C source file? It should compile in a C++, also, if it's standard C.

With non-static data in my C++ files I'm using this:

Code:

struct hold_value
{
    int value;
};

//...

struct hold_value local = { };
local.value = 0;

That's file within functions, but doesn't help when I need, e.g., a static constant. For now I'm just "sucking it up" and leaving out the .* for those and luckily most of those structures are ones I wrote.
ta0kira

PS Comeau does compile it in C99 mode but not in C++ mode. Did they just decide to leave this out of C++?

PPS This is a project for "the masses," so I'm better off doing it the way I have in this post. Making assumptions isn't too big of a deal with the static data I have, but it does make for an irritating code inconsistency.

P3S I suppose I could just extern those statics and put them in C sources, then __attribute__ ((visibility("internal"))) them...

osor · 04-12-2008, 03:41 PM

There are two syntaxes for designated initializers in the GNU Compiler Collection: the C99 one and the GNU-specific one. The C99 one will only work with gcc (and only I believe with --std={gnu,c99,gnu99}), the GNU-specific one will work with gcc and g++. The downside is that you lose portability to other C compilers which would have understood the first syntax fine (so I guess this is a trade-off which you have to consider in your project).

The syntax you used earlier is that of the C99 standard. If you want the GNU-extension equivalent, try:

Code:

struct
{
    int value;
} local = { value : 0 };

(the above should work on both gcc and g++).

dmail · 04-12-2008, 03:45 PM

Quote:

If it's part of C, why won't g++ compile it even when it's in a C source file? It should compile in a C++, also, if it's standard C.

Because it is not part of C++, in this language we use constructors yet some features similar to this are added with c++ox. I do not understand what you mean by "it's in a C source file", a cpp source file does not have to end with ".cpp", in fact I always use ".h" and ".c" for C++ files.

edit well I don't use ".c" but you would if you wanted.

ta0kira · 04-12-2008, 08:32 PM

Quote:

Originally Posted by osor

The syntax you used earlier is that of the C99 standard. If you want the GNU-extension equivalent, try:

Code:

struct
{
    int value;
} local = { value : 0 };

(the above should work on both gcc and g++).

Yes! That's exactly what I need. No worries about it being a GNU extension since I already use __attribute__ gratuitously for security reasons. My only portability requirement is that it work on all *nixes with gcc. I'd rather impose that limitation than forgo the security provided by hiding symbols (though admittedly not all binary formats support those attributes.) Thanks!
ta0kira

ta0kira · 04-12-2008, 08:59 PM

Quote:

Originally Posted by dmail

Because it is not part of C++, in this language we use constructors yet some features similar to this are added with c++ox. I do not understand what you mean by "it's in a C source file", a cpp source file does not have to end with ".cpp", in fact I always use ".h" and ".c" for C++ files.

edit well I don't use ".c" but you would if you wanted.

Yes, I also find that to be an irritating inconsistency. When I write a C file with .h, I really mean for it to be a C file and I don't want to have to use

Code:

#ifdef __cplusplus
extern "C" {
#endif

or include it in C++ files with extern "C". The problem is that initial versions of C++ didn't have the foresight to avoid .h standard headers, so now it's a habit of the user base. Anyway, that's another story altogether.
ta0kira

ta0kira · 04-12-2008, 09:08 PM

Is there any way around using extra braces to initialize unions?

Code:

const char name[] = "name";

static struct
{
	int value;
	union {
	const char  *single;
	const char **multi; };
} local = { value: 0, { single: name } };

If not, it isn't that big of a deal...
ta0kira

osor · 04-13-2008, 02:57 PM

Quote:

Originally Posted by ta0kira

Is there any way around using extra braces to initialize unions?

I don’t think so.