Temporarily disable std_vector.i?

[Russell E. Owen-4]

(Sorry if this is a duplicate; the first attempt didn't show up here).

I am having some issues with shadowed constructors that I think are
caused by using std_vector.i

Some of our classes have multiple constructors such as this:
Foo::Foo(std::vector<double> &values)
Foo::Foo(std::vector<boost::shared_ptr<FancyClass> > &fancyClasses)

and our SWIG file wraps the class Foo and also wraps the arguments as so:
%template(VectorDouble) std::vector<double>;
%template(VectorFancyClass)std::vector<boost::shared_ptr<FancyClass> >;

SWIG complains that the latter constructor is shadowed by the former.

As far as I can tell this is because both std::vector<double> and
std::vector<boost::shared_ptr<some fancyclass> > have been templated
after including std_vector.i. Thus SWIG is trying to support all of the
following forms of Foo constructor:
1) an explicitly constructed VectorDouble
2) a python list of doubles (due to std_vector.i and much appreciated)
3) an explicitly constructed VectorFancyClass
4) a python list of FancyClasses (due to std_vector.i and not necessary)
and the two python list versions (2 and 4) are colliding with each other.

I suspect that both Foo constructors are actually available, and that
only case (4) is unavailable. If so, we can live with it. But I would
rather explicitly disable std_vector.i for VectorFancyClass if there is
some easy way to do this.

I realize I could just include std_vector.i at the very end, but that
happens to be a headache due to the way we're including it right now (in
a common .i file shared by all others -- maybe that is a mistake).

Anyone have any suggestions?

-- Russell


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

[wsfulton]

Russell E. Owen wrote:

> (Sorry if this is a duplicate; the first attempt didn't show up here).
>
> I am having some issues with shadowed constructors that I think are
> caused by using std_vector.i
>
> Some of our classes have multiple constructors such as this:
> Foo::Foo(std::vector<double> &values)
> Foo::Foo(std::vector<boost::shared_ptr<FancyClass> > &fancyClasses)
>
> and our SWIG file wraps the class Foo and also wraps the arguments as so:
> %template(VectorDouble) std::vector<double>;
> %template(VectorFancyClass)std::vector<boost::shared_ptr<FancyClass> >;
>
> SWIG complains that the latter constructor is shadowed by the former.
>
> As far as I can tell this is because both std::vector<double> and
> std::vector<boost::shared_ptr<some fancyclass> > have been templated
> after including std_vector.i. Thus SWIG is trying to support all of the
> following forms of Foo constructor:
> 1) an explicitly constructed VectorDouble
> 2) a python list of doubles (due to std_vector.i and much appreciated)
> 3) an explicitly constructed VectorFancyClass
> 4) a python list of FancyClasses (due to std_vector.i and not necessary)
> and the two python list versions (2 and 4) are colliding with each other.
>
> I suspect that both Foo constructors are actually available, and that
> only case (4) is unavailable. If so, we can live with it. But I would
> rather explicitly disable std_vector.i for VectorFancyClass if there is
> some easy way to do this.
>
> I realize I could just include std_vector.i at the very end, but that
> happens to be a headache due to the way we're including it right now (in
> a common .i file shared by all others -- maybe that is a mistake).
>
> Anyone have any suggestions?

I don't see why SWIG is doing this and I can't replicate this problem. I
suggest you post a complete standalone example demonstrating it by
modifying below...

%module example

%include <std_vector.i>

%inline %{
#include <boost/shared_ptr.hpp>
struct FancyClass {};
struct Foo {
   Foo(std::vector<double>&) {}
   Foo(std::vector<FancyClass>) {}
};
%}


%template(VectorDouble)  std::vector<double>;
%template(VectorFancyClass)  std::vector<boost::shared_ptr<FancyClass> >;

William

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

[Russell E. Owen-4]

On Nov 1, 2009, at 12:59 PM, William S Fulton wrote:

> Russell E. Owen wrote:
>> (Sorry if this is a duplicate; the first attempt didn't show up  
>> here).
>> I am having some issues with shadowed constructors that I think are  
>> caused by using std_vector.i
>> Some of our classes have multiple constructors such as this:
>> Foo::Foo(std::vector<double> &values)
>> Foo::Foo(std::vector<boost::shared_ptr<FancyClass> > &fancyClasses)
>> and our SWIG file wraps the class Foo and also wraps the arguments  
>> as so:
>> %template(VectorDouble) std::vector<double>;
>> %template
>> (VectorFancyClass)std::vector<boost::shared_ptr<FancyClass> >;
>> SWIG complains that the latter constructor is shadowed by the former.
>> As far as I can tell this is because both std::vector<double> and  
>> std::vector<boost::shared_ptr<some fancyclass> > have been  
>> templated after including std_vector.i. Thus SWIG is trying to  
>> support all of the following forms of Foo constructor:
>> 1) an explicitly constructed VectorDouble
>> 2) a python list of doubles (due to std_vector.i and much  
>> appreciated)
>> 3) an explicitly constructed VectorFancyClass
>> 4) a python list of FancyClasses (due to std_vector.i and not  
>> necessary)
>> and the two python list versions (2 and 4) are colliding with each  
>> other.
>> I suspect that both Foo constructors are actually available, and  
>> that only case (4) is unavailable. If so, we can live with it. But  
>> I would rather explicitly disable std_vector.i for VectorFancyClass  
>> if there is some easy way to do this.
>> I realize I could just include std_vector.i at the very end, but  
>> that happens to be a headache due to the way we're including it  
>> right now (in a common .i file shared by all others -- maybe that  
>> is a mistake).
>> Anyone have any suggestions?
>
> I don't see why SWIG is doing this and I can't replicate this  
> problem. I suggest you post a complete standalone example  
> demonstrating it...

Here is my example (slightly longer than you requested, but short  
enough, I trust, to serve):

*** swigtest.h ***

#include <iostream>
#include <vector>

namespace test {
     class Bar {
     public:
         explicit Bar::Bar(int val=0) : intVal(val) {};
         int intVal;
     };

     class Foo {
     public:
         explicit Foo::Foo(std::vector<int> const &intVec) {
             std::cout << "Foo(";
             for (size_t ind = 0; ind < intVec.size(); ++ind)
                 std::cout << intVec[ind] << ", ";
             std::cout << ") constructor" << std::endl;
         }
         explicit Foo::Foo(std::vector<Bar> const &barVec) {
             std::cout << "Foo(";
             for (size_t ind = 0; ind < barVec.size(); ++ind)
                 std::cout << "Bar(" << barVec[ind].intVal << "), ";
             std::cout << ") constructor" << std::endl;
         }
     };

}

*** swigtest.i ***

%module swigtest
%{
#include "swigtest.h"
%}

%include "std_vector.i"
%template(IntVec) std::vector<int>;
%template(BarVec) std::vector<test::Bar>;
%include "swigtest.h"


*** runtest.py ***

#!/usr/bin/env python
# run swigtest

import swigtest

# these should work
iv = swigtest.IntVec()
iv.append(1)
iv.append(2)
iv.append(3)
swigtest.Foo(iv)

swigtest.Foo([1, 2, 3])

bv = swigtest.BarVec()
bv.append(swigtest.Bar(1))
bv.append(swigtest.Bar(2))
bv.append(swigtest.Bar(3))
swigtest.Foo(bv)

swigtest.Foo([swigtest.Bar(1), swigtest.Bar(2), swigtest.Bar(3)])

# these do horrible things, but that is not relevant to the problem  
being discussed:
#swigtest.Foo([1, 2, swigtest.Bar(3)])
#swigtest.Foo([swigtest.Bar(1), swigtest.Bar(2), 3])

When I build it I get a warning about a shadowed method (see appended  
log). But when I run the test code it works as desired.

-- Russell

*** Log ***

rowen:swigtest rowen$ swig -o swigtest_wrap.cc -c++ -python -I/Users/
rowen/lsst_home/DarwinX86/external/boost/1.37.0/include -I/Library/
Frameworks/Python.framework/Versions/2.5/include/python2.5 -I/Library/
include swigtest.i
swigtest.h:24: Warning(509): Overloaded method  
test::Foo::Foo(std::vector< test::Bar,std::allocator< test::Bar > >  
const &) is shadowed by test::Foo::Foo(std::vector<  
int,std::allocator< int > > const &) at swigtest.h:18.

rowen:swigtest rowen$ g++ -o swigtest_wrap.os -c -g -Wall -O3 -
DLSST_HAVE_TR1=1 -DLSST_LITTLE_ENDIAN=1 -fno-strict-aliasing -fPIC -I/
Users/rowen/lsst_home/DarwinX86/external/boost/1.37.0/include -I/
Library/Frameworks/Python.framework/Versions/2.5/include/python2.5 -I/
Library/include swigtest_wrap.cc
swigtest_wrap.cc: In member function  
‘swig::PySequence_Ref<T>::operator T() const [with T = int]’:
swigtest_wrap.cc:3133: warning: ‘v’ may be used uninitialized in this  
function

rowen:swigtest rowen$ g++ -o _swigtest.so  -bundle -undefined suppress  
-flat_namespace swigtest_wrap.os -L/Users/rowen/lsst_home/DarwinX86/
external/boost/1.37.0/lib -L/Library/Frameworks/Python.framework/
Versions/2.5/lib/python2.5/config

rowen:afw-1000 rowen$ swig -version

SWIG Version 1.3.36

Compiled with g++ [i386-apple-darwin9.4.0]
Please see http://www.swig.org for reporting bugs and further  
information

rowen:swigtest rowen$ ./runtest.py
Foo(1, 2, 3, ) constructor
Foo(1, 2, 3, ) constructor
Foo(Bar(1), Bar(2), Bar(3), ) constructor
Foo(Bar(1), Bar(2), Bar(3), ) constructor



------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

[Russell E. Owen-4]

In article <4AEDF6C0.1070902@...>,
 William S Fulton <wsf@...> wrote:


On Nov 1, 2009, at 12:59 PM, William S Fulton wrote:

> Russell E. Owen wrote:
> > I am having some issues with shadowed constructors that I think are caused
> > by
> > using std_vector.i
> > Some of our classes have multiple constructors such as this:
> > Foo::Foo(std::vector<double> &values)
> > Foo::Foo(std::vector<boost::shared_ptr<FancyClass> > &fancyClasses)
> > and our SWIG file wraps the class Foo and also wraps the arguments as so:
> > %template(VectorDouble) std::vector<double>;
> > %template(VectorFancyClass)std::vector<boost::shared_ptr<FancyClass> >;
> > SWIG complains that the latter constructor is shadowed by the former.
> > As far as I can tell this is because both std::vector<double> and
> > std::vector<boost::shared_ptr<some fancyclass> > have been templated after
> > including std_vector.i. Thus SWIG is trying to support all of the following
> > forms of Foo constructor:
> > 1) an explicitly constructed VectorDouble
> > 2) a python list of doubles (due to std_vector.i and much appreciated)
> > 3) an explicitly constructed VectorFancyClass
> > 4) a python list of FancyClasses (due to std_vector.i and not necessary)
> > and the two python list versions (2 and 4) are colliding with each other.
> > I suspect that both Foo constructors are actually available, and that only
> > case (4) is unavailable. If so, we can live with it. But I would rather
> > explicitly disable std_vector.i for VectorFancyClass if there is some easy
> > way to do this.
> > I realize I could just include std_vector.i at the very end, but that
> > happens
> > to be a headache due to the way we're including it right now (in a common
> > .i
> > file shared by all others -- maybe that is a mistake).
> > Anyone have any suggestions?
>
> I don't see why SWIG is doing this and I can't replicate this problem. I
> suggest you post a complete standalone example demonstrating it...

Here is my example (slightly longer than you requested, but short
enough, I trust, to serve)

*** swigtest.h ***

#include <iostream>
#include <vector>

namespace test {
   class Bar {
   public:
       explicit Bar::Bar(int val=0) : intVal(val) {};
       int intVal;
   };

   class Foo {
   public:
       explicit Foo::Foo(std::vector<int> const &intVec) {
           std::cout << "Foo(";
           for (size_t ind = 0; ind < intVec.size(); ++ind)
               std::cout << intVec[ind] << ", ";
           std::cout << ") constructor" << std::endl;
       }
       explicit Foo::Foo(std::vector<Bar> const &barVec) {
           std::cout << "Foo(";
           for (size_t ind = 0; ind < barVec.size(); ++ind)
               std::cout << "Bar(" << barVec[ind].intVal << "), ";
           std::cout << ") constructor" << std::endl;
       }
   };

}

*** swigtest.i ***

%module swigtest
%{
#include "swigtest.h"
%}

%include "std_vector.i"
%template(IntVec) std::vector<int>;
%template(BarVec) std::vector<test::Bar>;
%include "swigtest.h"


*** runtest.py ***

#!/usr/bin/env python
# run swigtest

import swigtest

# these should work
iv = swigtest.IntVec()
iv.append(1)
iv.append(2)
iv.append(3)
swigtest.Foo(iv)

swigtest.Foo([1, 2, 3])

bv = swigtest.BarVec()
bv.append(swigtest.Bar(1))
bv.append(swigtest.Bar(2))
bv.append(swigtest.Bar(3))
swigtest.Foo(bv)

swigtest.Foo([swigtest.Bar(1), swigtest.Bar(2), swigtest.Bar(3)])

# this is commented out because it aborts or send Foo garbage
# it may or may not be relevant to the problem being discussed
# I suspect the abort or garbage is a swig bug in any case
#swigtest.Foo([1, 2, swigtest.Bar(3)])
#swigtest.Foo([swigtest.Bar(1), swigtest.Bar(2), 3])

When I build it I get a warning about a shadowed method (see appended
log). But when I run the test code it works as desired.



I also found that if I simply move the swigtest.i line:
%template(BarVec) std::vector<test::Bar>;
after the line:
%include "swigtest.h"
then the problem goes away (though one can no longer provide a plain
python list of Bar). Also it solves the problem from the commented-out
lines of the test code: instead of aborting or sending Foo garbage, swig
correctly detects the mixed type list and rejects it!

I would prefer a solution that allows a plain list of Bar and correctly
rejects lists of mixed types. But barring such a solution, simply
templating the list of Bar at the end will do.

-- Russell

*** Log ***

rowen:swigtest rowen$ swig -o swigtest_wrap.cc -c++ -python
-I/Users/rowen/lsst_home/DarwinX86/external/boost/1.37.0/include
-I/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5
-I/Library/include swigtest.i
swigtest.h:24: Warning(509): Overloaded method
test::Foo::Foo(std::vector< test::Bar,std::allocator< test::Bar > >
const &) is shadowed by test::Foo::Foo(std::vector< int,std::allocator<
int > > const &) at swigtest.h:18.

rowen:swigtest rowen$ g++ -o swigtest_wrap.os -c -g -Wall -O3
-DLSST_HAVE_TR1=1 -DLSST_LITTLE_ENDIAN=1 -fno-strict-aliasing -fPIC
-I/Users/rowen/lsst_home/DarwinX86/external/boost/1.37.0/include
-I/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5
-I/Library/include swigtest_wrap.cc
swigtest_wrap.cc: In member function swig::PySequence_Ref<T>::operator
T() const [with T = int]:
swigtest_wrap.cc:3133: warning: v may be used uninitialized in this
function

rowen:swigtest rowen$ g++ -o _swigtest.so  -bundle -undefined suppress
-flat_namespace swigtest_wrap.os
-L/Users/rowen/lsst_home/DarwinX86/external/boost/1.37.0/lib
-L/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/config

rowen:afw-1000 rowen$ swig -version

SWIG Version 1.3.36

Compiled with g++ [i386-apple-darwin9.4.0]
Please see http://www.swig.org for reporting bugs and further information

rowen:swigtest rowen$ ./runtest.py
Foo(1, 2, 3, ) constructor
Foo(1, 2, 3, ) constructor
Foo(Bar(1), Bar(2), Bar(3), ) constructor
Foo(Bar(1), Bar(2), Bar(3), ) constructor

P.S. sorry if this is a duplicate; my reply to the mailing list has not
yet appeared on gmane. Even if it is a duplicate, this version has
additional information.


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

[Josh Cherry]

On Mon, 2 Nov 2009, Russell Owen wrote:

> When I build it I get a warning about a shadowed method (see appended
> log). But when I run the test code it works as desired.

I'm not sure what the problem is.  It sounds like you're just getting a
harmless warning (which I would expect, since the two conversions have the
same "priority").

Josh


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

[Russell E. Owen-4]

In article
<Pine.LNX.4.64.0911022004380.15130@...>,
 Josh Cherry <jcherry@...> wrote:

> On Mon, 2 Nov 2009, Russell Owen wrote:
>
> > When I build it I get a warning about a shadowed method (see appended
> > log). But when I run the test code it works as desired.
>
> I'm not sure what the problem is.  It sounds like you're just getting a
> harmless warning (which I would expect, since the two conversions have the
> same "priority").

There are two problems:
- The warning is wrong. The constructors are all available, despite
SWIG's claim that one has been shadowed. Clearly something is wrong (see
next item), but it is more subtle.  Both conversions and all the
constructors work as expected.
- The resulting library is not safe. It is easy to cause an abort, as
shown by the commented-out portions of the code.

I don't really understand the latter problem, since clearly SWIG does
some type checking when it walks through a list. If one fixes the
problem as per my previous email then SWIG will properly reject a list
of mixed values.

-- Russell


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

[Josh Cherry]

On Tue, 3 Nov 2009, Russell E. Owen wrote:

> There are two problems:
> - The warning is wrong. The constructors are all available, despite
> SWIG's claim that one has been shadowed. Clearly something is wrong (see
> next item), but it is more subtle.  Both conversions and all the
> constructors work as expected.

Here's my understanding of what's happening.  Every type conversion has a
precedence (many defined in swig.swg).  These are used in cases of
overloading to decide what order to use when looking for a matching
signature.  If two types have the same precedence (e.g., two vectors),
what should SWIG do?  It generates code to use both, but one must come
first.  It might be that the same input argument could match either check,
and it would be arbitrary which signature got called.  SWIG can't know, so
it issues a warning.  Perhaps the warning is poorly worded, but other than
that I'm not sure what behavior would be preferable.

> - The resulting library is not safe. It is easy to cause an abort, as
> shown by the commented-out portions of the code.
>
> I don't really understand the latter problem, since clearly SWIG does
> some type checking when it walks through a list. If one fixes the
> problem as per my previous email then SWIG will properly reject a list
> of mixed values.

It's not clear to me that this is related.  SWIG should check all of the
list members, but the handling of this has gone though various changes.
Why not check whether it has anything to do with overloading?

As a work-around, you can use %pythonprepend to stop bad stuff from
happening.

Josh


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user