Re: [Swig-user] Correct signature for templated definitions?

[William S F. <ws...@fu...>]

On 16/09/13 21:38, Thomas Maslach wrote:
>
> I have a class, myStlVector, that derives off std::vector.  It gets instantiated like so (and I included a typedef):
>
> typedef myStlVector < myt::Object * > ObjectList;
> %template (ObjectList) myStlVector < myt::Object * >;
>
> When I generate the wrapped code and look at the cxx file of the code, I noticed the signature of ObjectList is:
>
> static swig_type_info _swigt__p_myStlVectorT_myt__Object_p_t = {"_p_myStlVectorT_myt__Object_p_t", "myt::ObjectList *|myStlVector< myt::Object * > *", 0, 0, (void*)0, 0};
>
> However, I have another module which %imports the above interface file.  Here, my signature for ObjectList is different:
>
> static swig_type_info _swigt__p_myStlVectorT_myt__Object_p_std__allocatorT_myt__Object_p_t_t = {"_p_myStlVectorT_myt__Object_p_std__allocatorT_myt__Object_p_t_t", "myStlVector< myt::Object *,std::allocator< myt::Object * > > *|myt::ObjectList *|myStlVector< myt::Object * > *", 0, 0, (void*)0, 0};
>
> As you can see, the former one does not contain defaulted arguments, the latter one does.  Which one should be the correct one? I believe this is causing me problems as when I use myStlVector in the latter module as it has no members.  I believe it is because swig doesn't realize the second stl vector is the same as the first.
>
> I've posted something previously with regard to this, but am attempting to take this one step at a time in solving this time around.. I also have posted a bug that is probably related to this: http://sourceforge.net/p/swig/bugs/1332/.  I'm not 100% sure it's the same thing, haven't been able to prove that to myself.  But, it is the same type of problem.
>
> Any help would be appreciated - thanks!  I've been hitting this issue, unfortunately, quite a bit!
>
> Oh, and I just switched from .10 to .11.  Both exhibit this issue..
I have a feeling this was introduced in some type system improvements in 
swig-2.0.5 which also made things worse in some situations. I think 
those situations are when the type information is missing when using 
particular types. Eg, SWIG parsing the STL vector before the %template. 
I realise that isn't much to go on and it is also quite hard to debug. 
You could also try modifying %template to add in the default parameters 
you left out.  Unless you fancy debugging the SWIG source to fix this, I 
would finally resort to going back to/trying out swig-2.0.4. This will 
be on the long term fix list, please file a bug with full source to 
replicate and whether or not it works with swig-2.0.4.

William