>> Nifty :-) Actually I've believed that **declaration** of nested
>> structures is just a declaration, and no code/data will be generated
>> for that. But it turns out that I was wrong.
>
> This is an important difference between C and C++.
I'm sorry, but I'm confused a little bit: what is ``this'' that "is an
important difference between C and C++"? I've talked (the quote of me
above) about C compilers only, and I was wondering how you could
predicate that members of the nested structures (**from their
declarations**) become **real** members of the enclosing structure. :-)
Would you please explain me your thoughts?
But what has confused me more is your sample. A joke :-) The following
discussion in this message assumes that we are talking about C++
compilers only.
```
#ifdef __cplusplus
typedef struct _Time2Val _Time2Val
#endif
```
Okay, I understand that here you declares new ``typedef-name'' (the
"second" `_Time2Val`) for naming ``elaborated-type-specifier''
(`struct _Time2Val`). What I do **not** understand is why you've
introduced that ``typedef-name''? What is its purpose? To use it in
the next field declaration? But why not just use
``elaborated-type-specifier'' "directly" there?
The next statement is:
```
struct _Time2Val Time2Val;
```
I'm sorry, but it's "ill-formed"
> 9.1.7.3 Elaborated type specifiers [dcl.type.elab]
> 2 ... If the identifier resolves to a typedef-name ..., the
> elaborated-type-specifier is ill-formed.
> ...
> 3 ... Thus, in any elaborated-type-specifier, ... either the class or
> struct class-key shall be used to refer to a class (Clause 10)
> declared using the class or struct class-key.
Here is your sample on Matt Godbolt's ``Compiler explorer'':
https://godbolt.org/z/1RVfhQ (I simplified the sample, renamed
identifiers (`_Time2Val` -> `A`; `SSVARIANT` -> `B`; `Time2Val` ->
`a`) and removed the anonymous `union` -- it doesn't play a role there).
GCC (and some others (clang, icc, but not msvc)) failed to compile the
sample with this error (after "translating" names back): "using
typedef-name 'SSVARIANT::{unnamed union}::_Time2Val' after 'struct'" --
this what [dcl.type.elab] (2) is talking about.
But it doesn't matter, though. What I really want to understand is what
did you want to do, Hao. Please, explain, it's very important to me.
And what I've planned to post on the next Tuesday is something like
this:
```
define MSOLEDBSQL_H_DECL_VAR_TYPES do { \
struct _Time2Val { \
DBTIME2 tTime2Val; \
BYTE bScale; \
}; \
struct _DateTimeVal { \
... and so on: declare all "nested" structs here ..
}; \
} while (0)
#ifndef __cplusplus
MSOLEDBSQL_H_DECL_VAR_TYPES;
#endif
struct SSVARIANT {
/* declaration of some fields */
#ifdef __cplusplus
MSOLEDBSQL_H_DECL_VAR_TYPES;
#endif
union {
/* declaration of some other fields */
_Time2Val Time2Val;
_DateTimeVal DateTimeVal;
...
};
};
```
May be this is not a sophisticated solution, but it's a simple one (for
me) and it avoids double declaration problem.
On 3/2/2019 7:38 AM, Liu Hao wrote:
> 在 2019/3/2 上午2:13, Ruslan Garipov 写道:
>>> This can be verified by printing the size of the enclosing struct
>>> using GCC with our header, then comparing it with the result using
>>> MSVC and Microsoft header.
>>
>> Nifty :-) Actually I've believed that **declaration** of nested
>> structures is just a declaration, and no code/data will be generated for
>> that. But it turns out that I was wrong.
>>
>
> This is an important difference between C and C++.
>
> Well I think we may try this:
>
> ```
> struct _Time2Val
> {
> // some fields...
> };
>
> struct SSVARIANT
> {
> // some fields...
> union // anonymous union
> {
> #ifdef __cplusplus
> // The elaborated-type-specifier will reference the struct
> // in the global namespace and its use is mandatory here.
> typedef struct _Time2Val _Time2Val
> #endif
> struct _Time2Val Time2Val;
> };
> };
> ```
>
>
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
