From: William S F. <ws...@fu...> - 2013-01-08 22:59:13
|
On 08/01/13 14:20, Vladimir Kalinin wrote: > Hello William, > > I work for Open Design Alliance (www.opendesign.com) > (We are not listed on the projects page, and that > may be fixed. Actually, I was not aware of that page existence until > recently.) You should be able to post a patch quite easily to the relevant page at https://github.com/swig/www/blob/master/projects.ht containing a description of Open Design Alliance that you'd like to see on the web page. > > We are using SWIG for quite a while now, and with some success. Last > version of our product contains stable version of .NET wrappers > generated by SWIG. Of course, due to the size of our API (hundreds of > header files), there are some difficult places that SWIG couldn't quite handle. > We use directors extensively, and there are few issues in directors > support that were very limiting. The main problem is lacking > "csdirectorin" "pre:" and "post" code attributes in C# module. Without them it is > not trivial to marshal strings and smart-pointers back and forth > between user callback code and native code. (especially by reference) > I propose a patch introducing this support (with test). > It also fixes 2 minor issues in director code generation that are > difficult to come by until "csdirectorin" attribute is extended. > The first is that "ref" types used in directors lead to invalid > signature generation (the type array used to match methods possibly > overloaded by user). typeof(ref T) is used instead of > typeof().MakeByRefType() > The second is that ignored director methods are not completely ignored > - if there was a %typemap(imtype, "directorinattributes") it is not > skipped for ignored method. > > The issue was discussed in a mailing list long ago (see e.g. > http://permalink.gmane.org/gmane.comp.programming.swig/16385) > I proposed a patch a year and a half ago http://sourceforge.net/p/swig/patches/268/ > Attached to this mail is a git version of the patch, which is easier > to review. Thanks very much, I'll review that very shortly. > > The second problem is Unicode string literals. (Strings like L"Str" ) > In our code all the strings are wchar_t based and such literals occur > in headers from time to time. I proposed a workaround some time ago: > http://sourceforge.net/p/swig/bugs/971/, > but recently I put some work to it and implemented a full solution. > See the patch attached. The wide literals may occur in default > arguments and in expressions. In both cases they are correctly parsed. > Wide char literals are not unescaped while parsing, because they may > contain escaped characters not fitting into "char" type. If the target > language wants to use them but cannot handle C escape codes, language > module itself may do the necessary conversion. > > Usage example: > > %module(directors="1") MyModule > %include "wchar.i" > %feature("director") MyClass; > %csconst(1); > > class MyClass > { > public: > static const wchar_t * const myConst = L"MyWideCharConst\x234"; > virtual void myFunc(const wchar_t* myString = L"MyWideChar\x1234Literal\555"); > virtual ~MyClass(); > }; > > Generated C# wrapper code: > > public class MyClass : IDisposable { > ... > public const string myConst = "MyWideCharConst\x234"; > } > > Generated C++ proxy code: > class SwigDirector_MyClass : public MyClass, public Swig::Director { > public: > SwigDirector_MyClass(); > virtual void myFunc(wchar_t const *myString = L"MyWideChar\x1234Literal\555"); > ... > }; > > > These cases may seem marginal to non C# users, but I think we are not unique > with our requirements and these patches may benefit other users. (Of course we may > continue using locally forked swig version, > but it is rather inconvenient, especially for our clients, some of > which may want to regenerate .net wrappers from sources.) > No doubt someone will benefit, so let's aim to get these into the main SWIG distribution, it is better for all. It might be more complicated than you wish though. This support is already in the gsoc2009-matevz branch: https://github.com/swig/swig/blob/gsoc2009-matevz/Doc/Manual - See Cpp0x.html#Cpp0x_New_string_literals. This branch is my highest priority large integration into the mainline. So could I ask you to use this branch for this particular problem and provide any additional change in this area to that branch, or wait until I've merged it into master, probably by early Feb. Aside... anyone know how to provide a direct link so that the above .html file in github is rendered in a browser in github (it was possible in svnweb). William |