From: Vladimir K. <vka...@op...> - 2013-01-22 21:55:03
|
Hi, Any thoughts what should be done with unnamed structs? While working on nested classes support I met the test case "nested_structs", where the following is declared: %inline %{ struct Outer { struct { int val; } inner1, inner2, *inner3, inner4[1]; struct Named { int val; } inside1, inside2, *inside3, inside4[1]; } outer; Currently SWIG just outputs a warning that it cannot generate a wrapper for unnamed struct. Does anybody care about that, or it may be just left as is? We could e.g. adapt the old %name command to the task of assigning names to the unnamed structures, but on the other hand if someone is able to modify the header, he is as well able to give a name to the struct itself. Or perhaps some long unreadable name can be generated by default (like __unnamed_struct_SWIG_generated_123 (with unique counter)) This feature should probably be optional, as someone may not want to clutter scripting interface with such names. Other ideas? Vladimir |
From: William S F. <ws...@fu...> - 2013-01-23 18:30:37
|
On 22/01/13 21:54, Vladimir Kalinin wrote: > Hi, > > Any thoughts what should be done with unnamed structs? > > While working on nested classes support I met the test case > "nested_structs", where the following is declared: > > %inline %{ > struct Outer { > struct { > int val; > } inner1, inner2, *inner3, inner4[1]; > struct Named { > int val; > } inside1, inside2, *inside3, inside4[1]; > } outer; > > Currently SWIG just outputs a warning that it cannot generate a > wrapper for unnamed struct. > > Does anybody care about that, or it may be just left as is? > I don't recall anyone complaining about this before. Also we don't wrap global unnamed structs, so I would just leave it as ignored. > We could e.g. adapt the old %name command to the task of assigning > names to the unnamed structures, but on the other hand if someone > is able to modify the header, he is as well able to give a name to the > struct itself. > > Or perhaps some long unreadable name can be generated by default (like > __unnamed_struct_SWIG_generated_123 (with unique counter)) > This feature should probably be optional, as someone may not want to > clutter scripting interface with such names. > > Other ideas? > %feature and %rename require types, but there is no type associated with these anonymous structs. Some different mechanism would need to be invented as to how to address these types. Or we'd have to adapt them to use non standard syntax such as Outer::inner1. But given the lack of interest in providing wrappers for non-nested anonymous structs, I don't think it is worth putting any effort into this just yet. William |
From: Eric W. <ewm...@gm...> - 2013-01-23 19:39:23
|
On 1/23/13, William S Fulton <ws...@fu...> wrote: > On 22/01/13 21:54, Vladimir Kalinin wrote: >> Hi, >> >> Any thoughts what should be done with unnamed structs? >> >> While working on nested classes support I met the test case >> "nested_structs", where the following is declared: >> >> %inline %{ >> struct Outer { >> struct { >> int val; >> } inner1, inner2, *inner3, inner4[1]; >> struct Named { >> int val; >> } inside1, inside2, *inside3, inside4[1]; >> } outer; >> >> Currently SWIG just outputs a warning that it cannot generate a >> wrapper for unnamed struct. >> >> Does anybody care about that, or it may be just left as is? >> > I don't recall anyone complaining about this before. Also we don't wrap > global unnamed structs, so I would just leave it as ignored. FWIW, anonymous/unnamed structs were added as part of the C11 standard. Nobody probably complained about it before because it wasn't officially part of the standard until recently. But now that it is, this may pop up more often. Thanks, Eric -- Beginning iPhone Games Development http://playcontrol.net/iphonegamebook/ |
From: Vladimir K. <vka...@op...> - 2013-01-23 22:29:18
|
> On 1/23/13, William S Fulton <ws...@fu...> wrote: >> On 22/01/13 21:54, Vladimir Kalinin wrote: >>> Hi, >>> >>> Any thoughts what should be done with unnamed structs? >>> >>> While working on nested classes support I met the test case >>> "nested_structs", where the following is declared: >>> >>> %inline %{ >>> struct Outer { >>> struct { >>> int val; >>> } inner1, inner2, *inner3, inner4[1]; >>> struct Named { >>> int val; >>> } inside1, inside2, *inside3, inside4[1]; >>> } outer; >>> >>> Currently SWIG just outputs a warning that it cannot generate a >>> wrapper for unnamed struct. >>> >>> Does anybody care about that, or it may be just left as is? >>> >> I don't recall anyone complaining about this before. Also we don't wrap >> global unnamed structs, so I would just leave it as ignored. > > FWIW, anonymous/unnamed structs were added as part of the C11 > standard. Nobody probably complained about it before because it > wasn't officially part of the standard until recently. But now that it > is, this may pop up more often. Well, when/if there will be someone interested in that case, he might as well have some ideas about what he wants to see generated. Until then, as William suggests, I'll leave these structs ignored. Thanks for the input. Vladimir |
From: Vladimir K. <vka...@op...> - 2013-01-31 00:54:09
|
>> Hi, >> >> Any thoughts what should be done with unnamed structs? >> >> While working on nested classes support I met the test case >> "nested_structs", where the following is declared: >> >> %inline %{ >> struct Outer { >> struct { >> int val; >> } inner1, inner2, *inner3, inner4[1]; >> struct Named { >> int val; >> } inside1, inside2, *inside3, inside4[1]; >> } outer; >> >> Currently SWIG just outputs a warning that it cannot generate a >> wrapper for unnamed struct. >> >> Does anybody care about that, or it may be just left as is? >> > I don't recall anyone complaining about this before. Also we don't wrap > global unnamed structs, so I would just leave it as ignored. > >> We could e.g. adapt the old %name command to the task of assigning >> names to the unnamed structures, but on the other hand if someone >> is able to modify the header, he is as well able to give a name to the >> struct itself. >> >> Or perhaps some long unreadable name can be generated by default (like >> __unnamed_struct_SWIG_generated_123 (with unique counter)) >> This feature should probably be optional, as someone may not want to >> clutter scripting interface with such names. >> >> Other ideas? >> > %feature and %rename require types, but there is no type associated with > these anonymous structs. Some different mechanism would need to be > invented as to how to address these types. Or we'd have to adapt them to > use non standard syntax such as Outer::inner1. But given the lack of > interest in providing wrappers for non-nested anonymous structs, I don't > think it is worth putting any effort into this just yet. Some additional thoughts on the subject: Currently, working on nested classes, I already eliminated all the warnings in the csharp test suite except those generated by unnamed structures. There are about 20 of them. Also, I've broken/removed old C nested structures support that was copying struct definition to an %insert code and adding a typedef for it, generating a name from the outer class and data declarator names. It looked like this: struct Outer { struct { int val1; int val2; } data1, data2; }; and in the generated .c file there was inserted: typedef struct { int val1; int val2; } Outer_data1; typedef struct { int val1; int val2; } Outer_data2; and the proxy class looked like this: ... class Outer { public Outer_data1 data1; public Outer_data2 data2; } Of course this solution was rather ugly and brittle, but it was working, and some legacy code will no doubt be broken with this support removed. What I have in mind as a possible replacement is not wrapping the unnamed structure itself, but generating accessors to the nested data members. So that e.g. in C# proxy class would look like class Outer { public int data1_val1 {get;set;} public int data1_val2 {get;set;} public int data2_val1 {get;set;} public int data2_val2 {get;set;} } This solution requires no special features, and may be implemented almost entirely in the language module. But, of course, as you say, given the lack of interest, this may be postponed. Vladimir |
From: William S F. <ws...@fu...> - 2013-01-31 19:52:02
|
On 31/01/13 00:53, Vladimir Kalinin wrote: >>> Hi, >>> >>> Any thoughts what should be done with unnamed structs? >>> >>> While working on nested classes support I met the test case >>> "nested_structs", where the following is declared: >>> >>> %inline %{ >>> struct Outer { >>> struct { >>> int val; >>> } inner1, inner2, *inner3, inner4[1]; >>> struct Named { >>> int val; >>> } inside1, inside2, *inside3, inside4[1]; >>> } outer; >>> >>> Currently SWIG just outputs a warning that it cannot generate a >>> wrapper for unnamed struct. >>> >>> Does anybody care about that, or it may be just left as is? >>> >> I don't recall anyone complaining about this before. Also we don't wrap >> global unnamed structs, so I would just leave it as ignored. >> >>> We could e.g. adapt the old %name command to the task of assigning >>> names to the unnamed structures, but on the other hand if someone >>> is able to modify the header, he is as well able to give a name to the >>> struct itself. >>> >>> Or perhaps some long unreadable name can be generated by default (like >>> __unnamed_struct_SWIG_generated_123 (with unique counter)) >>> This feature should probably be optional, as someone may not want to >>> clutter scripting interface with such names. >>> >>> Other ideas? >>> >> %feature and %rename require types, but there is no type associated with >> these anonymous structs. Some different mechanism would need to be >> invented as to how to address these types. Or we'd have to adapt them to >> use non standard syntax such as Outer::inner1. But given the lack of >> interest in providing wrappers for non-nested anonymous structs, I don't >> think it is worth putting any effort into this just yet. > > Some additional thoughts on the subject: > > Currently, working on nested classes, I already eliminated all the warnings in the csharp test suite > except those generated by unnamed structures. There are about 20 of them. > Also, I've broken/removed old C nested structures support that was > copying struct definition to an %insert code and adding a typedef for it, generating a name > from the outer class and data declarator names. > It looked like this: > > struct Outer { > struct { int val1; int val2; } data1, data2; > }; > > and in the generated .c file there was inserted: > > typedef struct { int val1; int val2; } Outer_data1; > typedef struct { int val1; int val2; } Outer_data2; > Ah yes, the handling of nested structs is different in C and C++. Bah. So where we thought they were being ignored by SWIG, this is only true for C++. > and the proxy class looked like this: > ... > class Outer { > public Outer_data1 data1; > public Outer_data2 data2; > } > > Of course this solution was rather ugly and brittle, but it was working, and > some legacy code will no doubt be broken with this support removed. > > What I have in mind as a possible replacement is not wrapping the unnamed structure itself, but > generating accessors to the nested data members. So that e.g. in C# proxy class would look like > > class Outer { > public int data1_val1 {get;set;} > public int data1_val2 {get;set;} > public int data2_val1 {get;set;} > public int data2_val2 {get;set;} > } > > This solution requires no special features, and may be implemented > almost entirely in the language module. I'm not so keen on this. Multiple levels of nesting are then tricky. What if you have a named struct inside an anonymous struct. I think these anonymous structs should be handled the same as named structs, but somehow given a name. I was thinking we could give them the name of the first declared instance. So your example would be re-interpreted as if it was defined as: struct Outer { struct data1 { int val1; int val2; } data1, data2; }; and then the normal new nested struct handling is used. I think this would fall over in a heap with C++ though once you have templates, typedefs etc inside the structs, such as: struct Outer { struct { typedef int Integer; Integer val3; } data1, data2; }; I don't think you can address the Integer type from a global scope, which the wrappers would need to do. > But, of course, as you say, given the lack of interest, this may be > postponed. Mmm, unfortunately I misunderstood that lack of interest - it seems to be the case for C++ but not C. I would rather have the wrappers handled consistently for C and C++, but given the kind of problem I mentioned above, I don't think this will be possible. Perhaps the current approach is the best solution. To keep it the same for the new nested struct support is easy to implement for C++ (they are ignored), but for C, ideally you would code it up to keep it as it is now?? Do you think that is possible? William |
From: Vladimir K. <vka...@op...> - 2013-01-31 22:03:08
|
> On 31/01/13 00:53, Vladimir Kalinin wrote: >>>> Hi, >>>> >>>> Any thoughts what should be done with unnamed structs? >>>> >>>> While working on nested classes support I met the test case >>>> "nested_structs", where the following is declared: >>>> >>>> %inline %{ >>>> struct Outer { >>>> struct { >>>> int val; >>>> } inner1, inner2, *inner3, inner4[1]; >>>> struct Named { >>>> int val; >>>> } inside1, inside2, *inside3, inside4[1]; >>>> } outer; >>>> >>>> Currently SWIG just outputs a warning that it cannot generate a >>>> wrapper for unnamed struct. >>>> >>>> Does anybody care about that, or it may be just left as is? >>>> >>> I don't recall anyone complaining about this before. Also we don't wrap >>> global unnamed structs, so I would just leave it as ignored. >>> >>>> We could e.g. adapt the old %name command to the task of assigning >>>> names to the unnamed structures, but on the other hand if someone >>>> is able to modify the header, he is as well able to give a name to the >>>> struct itself. >>>> >>>> Or perhaps some long unreadable name can be generated by default (like >>>> __unnamed_struct_SWIG_generated_123 (with unique counter)) >>>> This feature should probably be optional, as someone may not want to >>>> clutter scripting interface with such names. >>>> >>>> Other ideas? >>>> >>> %feature and %rename require types, but there is no type associated with >>> these anonymous structs. Some different mechanism would need to be >>> invented as to how to address these types. Or we'd have to adapt them to >>> use non standard syntax such as Outer::inner1. But given the lack of >>> interest in providing wrappers for non-nested anonymous structs, I don't >>> think it is worth putting any effort into this just yet. >> >> Some additional thoughts on the subject: >> >> Currently, working on nested classes, I already eliminated all the warnings in the csharp test suite >> except those generated by unnamed structures. There are about 20 of them. >> Also, I've broken/removed old C nested structures support that was >> copying struct definition to an %insert code and adding a typedef for it, generating a name >> from the outer class and data declarator names. >> It looked like this: >> >> struct Outer { >> struct { int val1; int val2; } data1, data2; >> }; >> >> and in the generated .c file there was inserted: >> >> typedef struct { int val1; int val2; } Outer_data1; >> typedef struct { int val1; int val2; } Outer_data2; >> > Ah yes, the handling of nested structs is different in C and C++. Bah. > So where we thought they were being ignored by SWIG, this is only true > for C++. > >> and the proxy class looked like this: >> ... >> class Outer { >> public Outer_data1 data1; >> public Outer_data2 data2; >> } >> >> Of course this solution was rather ugly and brittle, but it was working, and >> some legacy code will no doubt be broken with this support removed. >> >> What I have in mind as a possible replacement is not wrapping the unnamed structure itself, but >> generating accessors to the nested data members. So that e.g. in C# proxy class would look like >> >> class Outer { >> public int data1_val1 {get;set;} >> public int data1_val2 {get;set;} >> public int data2_val1 {get;set;} >> public int data2_val2 {get;set;} >> } >> >> This solution requires no special features, and may be implemented >> almost entirely in the language module. > I'm not so keen on this. Multiple levels of nesting are then tricky. > What if you have a named struct inside an anonymous struct. The nested named struct will then be wrapped normally. These unnamed structures are just child declaration containers. There is no way to allocate/assign/destroy them in C/C++, therefore I see no reason to treat them as classes in the target language. > I think > these anonymous structs should be handled the same as named structs, but > somehow given a name. > > I was thinking we could give them the name of the first declared > instance. So your example would be re-interpreted as if it was defined as: > > struct Outer { > struct data1 { > int val1; > int val2; > } data1, data2; > }; > > and then the normal new nested struct handling is used. I think this > would fall over in a heap with C++ though once you have templates, > typedefs etc inside the structs, such as: > > struct Outer { > struct { > typedef int Integer; > Integer val3; > } data1, data2; > }; > > I don't think you can address the Integer type from a global scope, > which the wrappers would need to do. To give them a name means copying them to the generated .c file with a typedef prepended, so that these names would become visible to the C compiler. >> But, of course, as you say, given the lack of interest, this may be >> postponed. > Mmm, unfortunately I misunderstood that lack of interest - it seems to > be the case for C++ but not C. I would rather have the wrappers handled > consistently for C and C++, but given the kind of problem I mentioned > above, I don't think this will be possible. > > Perhaps the current approach is the best solution. To keep it the same > for the new nested struct support is easy to implement for C++ (they are > ignored), but for C, ideally you would code it up to keep it as it is > now?? Do you think that is possible? It is kind of hard to keep it as it was implemented previously, with reentering the parser, but, I think, similar behaviour can be emulated. In any case we should emit unnamed structure declaration to the generated .c file, to make a typedef visible to the C compiler, otherwise the wrapper won't compile. For C we can reliably recreate a structure declaration from the parsed state, and put it into an %insert in the global scope. This transformation can be done after the parsing. That is not as easy as the old implementation that copied unparsed text verbatim to make a typedef, but I see no way to to keep the old implementation, w/o creating a different grammar file for C parsing (yacc/bison do not support conditional grammar). Maybe it is possible though, I have to think about it some more. (In some cases this approach will work for C++ too, if there would be no complicated structure members.) Vladimir |