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

The problem is the final is a C++11 identifier with special meaning and it
is not been treated as an identifier when 'final' is part of a scope
identifier. Could you create a Github issue with this? I may have a fix for
it.

William

On Mon, 9 Dec 2019 at 08:57, Boro <[email protected]> wrote:

> Hi, here is some snippet which does not work. Thanks in advance.
>
> Stefan
> ————————————-
>
> %module finAuxPy
>
>
>
> template<class T>
>
> class ObjectDB
>
> {
>
> public:
>
>        static
>
>        bool insert(T *objectT);
>
>
>
>     static bool insert(typename final::smart_ptr<T>::type *objectT);
>
>
>
>        static final::smart_ptr<T>::type get(const std::string &name);
>
>
>
>        static bool remove(const std::string &name);
>
>
>
>        static void clear();
>
>
>
>        static bool contains(const std::string &name);
>
>
>
>        static std::vector<std::string> snapshot();
>
> };
>
>
>
> %template(DBInterpCurve) ObjectDB<CInterpCurve>;
>
> %template(DBInterpSurface) ObjectDB<CInterpSurface>;
>
> %template(DBNameCurve) ObjectDB<CNameCurve>;
>
> %template(DBYieldCurve) ObjectDB<CYieldCurve>;
>
>
> Note that we import some headers which explain the namespace final. But
> this doesn‘t seam matter here, as swig keeps on reporting an error.
>
>
> Von meinem iPhone gesendet
>
> Am 04.12.2019 um 20:39 schrieb William S Fulton <[email protected]>:
>
> 
> 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