On 27 February 2013 20:29, Vladimir Kalinin <vkalinin@opendesign.com> wrote:
>> There is a test "nested_structs" where following declaration is
>> wrapped:
>> %inline %{
>> struct Outer {
>>   struct {
>>     int val;
>>   } inner1, inner2, *inner3, inner4[1];
>>   struct Named {
>>     int val;
>>   } inside1, inside2, *inside3, inside4[1];
>> } outer;
>> %}
>> For this example SWIG ignores named nested structure name ("Named")
>> and instead treats it as unnamed.
>> Is that intentional?
>> Also, for unnamed structure, four different typedefs are generated, so
>> that in the target language outer.inner1 and outer.inner2 are totally
>> unrelated. Would it not be more logical to create one typedef and use
>> it for all the declarations?
>> I met that case in Java test suite testing nested classes handling,
>> and I don't know whether to change the test or fix the implementation
>> to emulate the old behaviour.
>> The nested wrappers are a bit hit and miss. Any inconsistencies should be
> tidied up, so in this case I would ensure the 'Named' struct is wrapped as
> a named nested struct.

Good. In my branch it is already so.

> Regarding unnamed nested structs, it would be better to have a common name,
> but how would you choose one? I don't think there is one ideal solution, so
> perhaps just keep it the same as it is now. Any better ideas?

I think any common type is better than 4 different ones.
In my implementation I scan the declaration list looking for the fist
empty "decl" attribute, that is something like simple
typedef struct {...} Name;
If there are none, I just use the fist declaration name to construct a
typedef name. Constructed typedef name is then used for all the declarations.
This way at least declarators having the same C type, have the same type
in the target language.

But typedef structs are different to unnamed structs such as the one you first mentioned. For nested unnamed structs that are typedefs, it sounds like you are doing the same as what is done for global unnamed structs that are typedefs, which is good, and also is no change from previous behaviour.

But for nested unnamed struct instances such as inner1 that you posted about, how do you choose the name of the type given there truly is no type name? In your example, do you then choose Outer_inner1 as the base type for inner1, inner2, inner3, inner4?

BTW, I kind of finished nested classes implementation. Java and C#
test suites are passing w/o errors (this nested C structures test case was
the last to examine).
Sounds good. I'll take a look when I can. I am thinking that we should create version 2.1 or even 3.0 using your nested classes, doxygen support and c++11 as they are all roughly ready.