From: Vladimir K. <vka...@op...> - 2013-01-10 23:57:03
|
> 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. What is the status of that branch? I mean - is someone still working on it or it is considered finished? Because, as you understand, it is a lot harder to fix someone's code than to write one's own. If there is an author available, I can show him a failing test case, and he may probably fix what needs to be fixed, or explain why it is not necessary/possible, or just say that he doesn't have the time, and then I'll have to fix it myself (after nested classes). Actually this is the full class I used for debugging wide char literals: struct MyClass { static const wchar_t * const myConst = L"MyWideCharCont\x234"; static const wchar_t myConstI = L'\34'; virtual void myFunc(const wchar_t* myString = L"MyWideChar\x1234Literal\555"); virtual void myFunc1(const char* myString = "MyCharLiteral\x12"); virtual void myFunc2(wchar_t myChar = L'\x1234'); // virtual void myFunc3(int myInt = L'\x1334'); virtual ~MyClass(); }; Commented out function reveals an unrelated bug in default parameters implementation - we don't retain deducted types of the default values and expressions. E.g. the constant: static const int x = '1'; would produce the wrapper static const int x = 1; Perhaps I should enter a bug about it, but as I understand bug tracking is in flux now, so this (rather insignificant) issue may wait. Vladimir |