From: William S F. <ws...@fu...> - 2007-10-03 22:59:25
|
David Piepgrass wrote: >>> I think I'm stuck. Have you had any luck Kevin? >>> >>> >> What I did was to patch in the capability to specify >> %feature("valuetype") on a member variable. If that is specified, it >> circumvents the logic that converts the type to a reference or > pointer, >> only for that one member. > > Yup, that was one of the three possibilities I suggested in my email an > hour ago. Sounds reasonable, although I wonder if that name is specific > enough. maybe %feature("rvalueattribute") is a better name (or do I > assume too much, thinking people know what an "rvalue" is?). In any case > it would be good if the name conveyed its association with > attributes/member variables, as it does not apply to methods or types. > >> Now hopefully we can work on a more general solution. I can get a > patch >> together and put it up in the issue tracker if that's appropriate. Is >> there an issue open for this one? > > Not that I know of. > This can also be fixed by changing the scope of the _result_ref by removing the enclosing local scope brackets and moving it into the scope of the wrapper function. However, it only works for Java and C# as the other languages use goto statements for error handling and you can't jump across variable initialization. I knew these goto statements would break something one day and here we have it. Anyway, the problem is only relevant to the %attribute macro, which isn't even in the documentation. I'd prefer to find an improvement to %attribute rather than have a new feature, but I'm not sure if you guys have looked at this possibility and I'm still to get familiar with all the various macros in attribute.i to really know atm. William |