From: Vladimir K. <vka...@op...> - 2013-01-09 11:57:39
|
> On Jan 8, 2013, at 4:59 PM, William S Fulton wrote: >> On 08/01/13 14:20, Vladimir Kalinin wrote: >> 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). I checked out that branch and it doesn't pass the test I quoted above. Anyway, if there is someone working on it, perhaps I'd better not interfere. It is unfortunate though, that corresponding bug on SF was not set to 'assigned'. That would have saved me a day's work. Vladimir |