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

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