Re: [Swig-user] Re: [Swig-devel] SWIG-1.3.28 release candidate

[Marcelo M. <mm...@ac...>]

It is fine, unexepected, but fine. What is happening is that the 'out' 
typemap of a named vector typemap
now returns a wrapper object when possible instead of a python copy, for 
example:
 

  %template(vector_int) vector<int>;

  std::vector<int> data () const;


used to return a python native vector, which is very expensive. I forgot 
to add the flag
to keep the old behavior, but I will added now. Anyway, you probably 
want to do this too:

  
namespace {
  %std_comp_methods(vector<int>);

 %template(vector_int) vector<int>;

 ...
}

That will add the 'comparison methods' (==, <=, >= !=, etc) to std::vector<int>,
then you can compare

     a = gclass.data()
     if a != ((1+5j), (2+5j), (3+5j), (4+5j), (5+5j)): 
          ....

and that will work for your tests in 1.3.27 and 1.3.28, and in other situations
like:

     a1 = vector_int()
     a2 = vector_int()
     ....
     if a1 != a2:
          ....

which doesn't work unless you use the %std_comp_methods().



And for the question, why we don't add the comparison methods by default to 
the std::vector<Type> class?, well, because in C++ the vector comparison methods
only make sense if 'Type' support them.

In the meantime, I will add the option to keep the old behavior and switch to the
new one.

Marcelo


PS: anonymous %templates, like 

%template() std::vector<int>;

always use copy 'out' typemaps that creates native python tuples since there is
no  way to represent them in other way in python.

 
Usually, if you only use small std::vectors, and really don't use the std::vector
C++ features, and the %template(Name) directive is there only to pass/receive
native python tuples into the C++ code, probably is better to use the anonymous 
form. The generated code in this way is much smaller, since no real python proxy 
classes are  generated.




Eric Blossom wrote:

>Hi,
>
>I've tried SWIG-1.3.28rc1 on GNU Radio (gnuradio-core), and it triggers a bunch of
>failures in our test code.  FWIW, our code has been working fine with SWIG
>1.3.{23,24,25,27}.   We use it to generate Python bindings.
>
>Here are a couple of examples:
>
>======================================================================
>FAIL: test_add_const_cc (__main__.test_head)
>----------------------------------------------------------------------
>Traceback (most recent call last):
>  File "./qa_add_and_friends.py", line 73, in test_add_const_cc
>    self.help_cc ((src_data,), expected_result, op)
>  File "./qa_add_and_friends.py", line 61, in help_cc
>    self.assertEqual (exp_data, result_data)
>AssertionError: ((1+5j), (2+5j), (3+5j), (4+5j), (5+5j)) != <gnuradio_swig_python.vector_complex_float; proxy of C++ std::vector<std::complex<float > > instance at 0x71a750>
>
>======================================================================
>FAIL: test_add_const_ii (__main__.test_head)
>----------------------------------------------------------------------
>Traceback (most recent call last):
>  File "./qa_add_and_friends.py", line 67, in test_add_const_ii
>    self.help_ii ((src_data,), expected_result, op)
>  File "./qa_add_and_friends.py", line 41, in help_ii
>    self.assertEqual (exp_data, result_data)
>AssertionError: (6, 7, 8, 9, 10) != <gnuradio_swig_python.vector_int; proxy of C++ std::vector<int > instance at 0x780140>
>
>
>
>Apparently something has changed with regard to template instantiation
>of STL vectors, and the <stl.i> typemaps aren't getting applied.
>
>
>
>Fragment of gnuradio.i:
>
>
>%{
>#include <gr_types.h>
>#include <stddef.h>		// size_t
>%}
>
>%feature("autodoc","1");
>
>%include <shared_ptr.i>
>%include <stl.i>
>%include <std_complex.i>
>
>
>typedef std::complex<float>		gr_complex;
>typedef std::complex<double>		gr_complexd;
>
>
>// instantiate the required template specializations
>namespace std {
>  %template(vector_uchar)	  vector<unsigned char>;
>  %template(vector_char)	  vector<char>;
>  %template(vector_short)	  vector<short>;
>  %template(vector_int)		  vector<int>;
>  %template(vector_float)	  vector<float>;
>  %template(vector_double)	  vector<double>;
>  %template(vector_complex_float) vector<std::complex<float> >;
>};
>
>// [snip]
>
>GR_SWIG_BLOCK_MAGIC(gr,vector_sink_i); // does some renaming, handles shared_ptr stuff
>
>gr_vector_sink_i_sptr gr_make_vector_sink_i ();
>
>class gr_vector_sink_i : public gr_sync_block {
> private:
>  gr_vector_sink_i ();
>
> public:
>  std::vector<int> data () const;
>};
>
>
>GR_SWIG_BLOCK_MAGIC(gr,vector_sink_c);  // does some renaming, handles shared_ptr stuff
>
>gr_vector_sink_c_sptr gr_make_vector_sink_c ();
>
>class gr_vector_sink_c : public gr_sync_block {
> private:
>  gr_vector_sink_c ();
>
> public:
>  std::vector<gr_complex> data () const;
>};
>
>
>
>Ideas?  Suggestions?
>
>Eric
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>for problems?  Stop!  Download the new AJAX search engine that makes
>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
>_______________________________________________
>Swig-user mailing list
>Swi...@li...
>https://lists.sourceforge.net/lists/listinfo/swig-user
>  
>