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

Done: https://github.com/swig/swig/issues/1679

Thanks and regards,
   Stefan

Am 10.12.2019 um 09:11 schrieb William S Fulton:
> 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] 
> <mailto:[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] <mailto:[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] <mailto:[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]
>>>         <mailto:[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