Re: [Swig-user] TypeError for std::vector<myClass *>

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

Bo Peng wrote:
> Dear developers,
> 
> I need to pass 'vector<myClass *>' to a few functions where objects of
> derived classes are passed.
> 
> Conceptually, the C++ code is like
> 
> class A {};
> class B : public A {};
> class C : public A {};
> int func(std::vector<A*>)
> 
> In the interface file,
> 
> namespace std
> {
>  %template(vectorA) vector<A*>;
> }
> 
> and in Python,
> 
> func([B(), C()])
> 
> This works ok for class A, B, C, but I am having difficulties in
> applying this technique to another class. They look all similar in
> C++, and in the interface file but I get
> 
> TypeError: in method 'new_heteroMating', argument 1 of type
> 'simuPOP::vectormating const &'
> 
> The C++ code is:
> 
> typedef std::vector<mating *> vectormating;
> class heteroMating : public mating
> {
> public:
> 	heteroMating(const vectormating & matingSchemes = vectormating(),
> 	             vectorlu newSubPopSize = vectorlu())
> };
> 
> I tried to trace what is going on, and find that in the previous case,
> vector<A*> is handled like (A is the baseOperator here):
> 
>   if (obj1) {
>     {
>       std::vector<simuPOP::baseOperator*,std::allocator<simuPOP::baseOperator
> * > > *ptr = (std::vector<simuPOP::baseOperator*,std::allocator<simuPOP::baseOperator
> * > > *)0;
>       res2 = swig::asptr(obj1, &ptr);
> 
> but for the latter case,
> 
>   if (obj0) {
>     res1 = SWIG_ConvertPtr(obj0, &argp1,
> SWIGTYPE_p_std__vectorTsimuPOP__mating_p_std__allocatorTsimuPOP__mating_p_t_t,
>  0  | 0);
>     if (!SWIG_IsOK(res1)) {
>       SWIG_exception_fail(SWIG_ArgError(res1), "in method '"
> "new_heteroMating" "', argument " "1"" of type '"
> "simuPOP::vectormating const &""'");
>     }
> 
> 
> It seems to me that SWIG is properly using a std::vector<> method to
> handle class baseOperator, but rely on SWIG pointer to handle class
> mating. What might be causing the problem? I guess what I need is some
> insights on why the generated interface file treat these two classes
> differently.  I would be happy to provide further details if needed.
> 

I suspect that SWIG has not parsed the definition of mating. SWIG should 
even generate a warning about this when it parses the definition of 
heteroMating. Try using SWIG -E to look at the preprocessor output.

William