From: William S F. <ws...@fu...> - 2013-01-10 22:49:46
|
On 09/01/13 11:57, Vladimir Kalinin wrote: >> 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. > Sorry to hear that, there are way too many bugs and patches to keep track of them all. If you don't provide a patch for the gsoc2009-matevz branch, I'll merge it in once I've merged the branch into master. William |