Re: Swig 3/4 vs. Swig 2: A parsing Problem?

Can you provide a small standalone snippet of code that compiles with a C++
compiler and fails with SWIG because final as a namespace name works fine
for me.

William

On Tue, 3 Dec 2019 at 17:58, Stefan Borovac <[email protected]>
wrote:

> Hi,
>
> I went back to the problem yesterday and I think I know what is going
> wrong.
> First of all, yes, the code snippet below can be parsed without a problem.
> Thanks for checking this. I replaced the variable-names before I sent it
> and this is the clou.
>
> In our project we have a namespace named "final" and since C++11 (or Swig
> 3.X),
> this is a C++ specifier.
> Whenever Swig 3.X/4.X comes across something like:
>     final::smart_ptr<AnyThing>::type AnyThingPtr;
> it considers this as a "final" specifier rather than a namespace
> indentifier.
> I think I can broadly remove the explicit scope and resolve the problem but
> I am still not 100% happy with Swig's interpretation.
>
> Thanks & regards,
>   Stefan
>
> Am 22.11.2019 um 08:40 schrieb William S Fulton:
>
>
>
> On Mon, 11 Nov 2019 at 18:02, Stefan Borovac <[email protected]>
> wrote:
>
>> Hi,
>>
>> I have taken over the maintenance of a larger library which exposes C++
>> functionality to Python via Swig.
>> Up to now we use Python 2.7.6 and Swig 2.0.10.
>> We will switch to Python 3.7.X or 3.8.X and thus would like to use Swig
>> 4.0.1.
>> In the new setup we observe a problem. The swig generator fails with a
>> simple
>> message "Syntax error at line X" and stops without generating any
>> wrapper code.
>> A simplified code fragment looks like this:
>>
>> /* File: SomethingPy.i */
>>
>> %{
>> typedef mySpace::smart_ptr<AnyThing>::type AnyThingPtr;
>> typedef mySpace::smart_ptr<AnyThing>::type AnotherThingPtr;
>> %}
>>
>> %rename(AnyThing) AnyThingPtr;
>> class AnyThingPtr
>> {
>>      public:
>>          %extend {
>>              std::map<std::string, double> doSomething(double *pOUTPUT,
>> [more simple Input])
>>              {
>>                  return  (*self)->Evaluate(pOUTPUT, [more simple input]);
>>              }
>>          }
>> };
>>
>> %rename(AnotherThing) AnotherThingPtr;
>> class AnotherThingPtr : public AnyThingPtr
>> {
>>      public:
>>          %extend {
>>              AnotherThingPtr( mySpace::smart_ptr<SomeThingElse>::type
>> somethingElsePtr, [more simple input])
>>              {
>>                      return new AnotherThingPtr( new
>> AnotherThing(somethingElsePtr, [more simple input]) );
>>              }
>>          }
>> };
>>
>> The error is related to "mySpace::smart_ptr<SomeThingElse>::type". This
>> type should simply be copied into
>> the wrapper code (as it is done with Swig 2.0.10). The pointer
>> declaration above is basically a templated
>> struct which holds a pointer definition (nowadays such a templated type
>> would be realised by a "using" declaration).
>>
>> So I am not a Swig-expert at all and for some reason we don't want to
>> change the definiton of the pointer now.
>> Would be great if you could give me a hint what is going differently in
>> Swig 4.0.1 (and also Swig 3.0.12).
>>
>>
> I removed the invalid code above (in square brackets) and it parses fine
> in swig-4.0.1. I suggest you run swig with the -E option to look at the
> preprocessed output so that you can see the invalid syntax. Post it
> somewhere and I'll have a look if you can't work it out.
>
> William
>
>
>

_______________________________________________
Swig-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/swig-user