discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Q's regarding C++ <-> SWIG <-> Python


From: Eric Blossom
Subject: Re: [Discuss-gnuradio] Q's regarding C++ <-> SWIG <-> Python
Date: Fri, 7 Jul 2006 19:07:13 -0700
User-agent: Mutt/1.5.9i

On Fri, Jul 07, 2006 at 07:24:26PM -0400, Michael Dickens wrote:
> It seems like the "usual" C constructs port easily between C++ /  
> SWIG / Python: char, short, int, long, float, double.  I'm fine in C+ 
> +, but SWIG and Python are new to me, and combining them I generally  
> take to be an SEP ("someone else's problem", thanks Douglas Adams).   
> Given my time constraints over the summer, I'm hoping that someone  
> else knows about these issues, and can provide some definitive  
> answers.  Thanks! - MLD
> 
> 1) What I need are std::vector's of the usual C types, as well as  
> references to gr-blocks.  In looking through gnuradio-core/src/lib/ 
> general and runtime, it looks like to get a std::vector<int> argument  
> in the constructor, what I need to do is something like:
> 
>       const std::vector<int> foo;
> 
> but "&foo" won't work?  ... at least it didn't for me.

Passing a non-const reference would require that python and C++ share the same
underlying data structure.  If the ref is const, or if the vector is
passed by value, then SWIG can safely make a copy of the Python data
for C++ to play with.

[You may need to instantiate a non-anonymous STL template in the .i file.
 What we're currently (mostly) using are anonymous (unnamed) templates.]

Non-anonymous template instantiation:

    // support vectors of these...
    namespace std {
      %template(x_vector_gr_block_sptr) vector<gr_block_sptr>;
    };


Anonymous template instantiation (lower cost, doesn't wrap all the STL vector 
cruft):

    // instantiate the required template specializations

    namespace std {
      %template()         vector<unsigned char>;
      %template()         vector<char>;
      %template()         vector<short>;
      %template()         vector<int>;
      %template()         vector<float>;
      %template()         vector<double>;
      %template()         vector<std::complex<float> >;
    };


N.B., there are some differences between SWIG versions as to how
(or if) the STL stuff works.  The idioms in use in the code are known
to work OK in SWIG 1.3.23, 1.3.24, 1.3.25, 1.3.27, 1.3.28, and 1.3.29
(1.3.26 had problems and was immediately replaced with 1.3.27.)

> OTOH, I can also so a std::vector<gr_block_sptr>'s via something like:
> 
>       const std::vector<gr_block_sptr> &foo;
> 
> ... or at least these seem to be the way things are done in the  
> code.  So no "&" for the usual types, but an "&" for sptr types?   
> Does this sound correct, or can anyone offer corrections?  Can  
> someone -briefly- explain these further?

Not true.  Take a look at this:

    GR_SWIG_BLOCK_MAGIC(gr,fir_filter_fff);

    gr_fir_filter_fff_sptr gr_make_fir_filter_fff (int decimation, const 
std::vector<float> &taps);

    class gr_fir_filter_fff : public gr_sync_decimator
    {
     private:
      gr_fir_filter_fff (int decimation, const std::vector<float> &taps);

     public:
      ~gr_fir_filter_fff ();

      void set_taps (const std::vector<float> &taps);
    };


> 2) Is it possible to do a 2d-matrix-like type with something built-in  
> to Python / SWIG / C++, such as the std::vector<std::vector<int>>?   
> Clearly I can do a 1d vector (as per (1) above) then mess around with  
> it internally (which is what I currently do) .. but I would certainly  
> prefer a better solution.

Not sure, ask on swig-user.

If you plan on messing with the contents of a vector in C++ and expect
Python to see the result, you're going to need a different approach
than the "it's safe to make a copy of the data" strategy currently
used.  You'll need to instantiate a real STL vector in Python, not use
a Python list or tuple.

> 3) Is it possible to assign default values to only -some- arguments  
> to the "friend" method?  I can see some codes which assign default  
> values to -all- arguments, while most do none.

It's a C++ thing.  Everything to the right of the first argument
with a default value must also have a default value.

> 4) Can I have multiple constructors, and thus multiple "friend"  
> methods .. in the SWIG context (clearly I can in just C++, but can  
> SWIG handle it correctly)?  For example, the constructor for a  
> "feedback" system typically requires 1 more argument than the  
> "feedforward" system (the feedback portion; both require the  
> feedforward portion) ... so I can either do 1 block with 2  
> constructors or create 2 blocks each with 1 constructor, to handle  
> the different cases.

Yes, you can have multiple constructors, but they need to have
different names.  (If they have the same name, C++ can sort them out
at compile time based on argument type at the calling site, but Python
can't do that because of its dynamic typing.)

If you've got more SWIG questions, they're probably better addressed
on the swig-user mailing list.  They're nice people too ;)
http://lists.sourceforge.net/lists/listinfo/swig-user

Have you tried the swig docs?
I'd start with these sections:

  http://www.swig.org/Doc1.3/SWIG.html#SWIG
  http://www.swig.org/Doc1.3/SWIGPlus.html#SWIGPlus
  http://www.swig.org/Doc1.3/Python.html#Python

Eric




reply via email to

[Prev in Thread] Current Thread [Next in Thread]