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

[Michael Dickens]

> 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);
>     };

OK.  So what's the difference between:

        const std::vector<float> &taps
and
        const std::vector<float> taps

in terms of the way Python -> SWIG -> C++ works?  In C++, the "&" is  
a reference to - no copying, and "const" means that you can't change  
it at the destination (or, rather that the compiler will complain if  
you try to ;).  Does a reference (not copying) really hold true for  
moving data from Python to C++?  That would imply that the underlying  
data structure is the same between them ... which I can understand  
for the "usual" types (char, short, int, long, float, double,  
etc...) ... so how would that work with a C++ class such as  
std::vector?  Does Python actually implement a "list" (e.g. "[5,6]")  
as a std::vector, and hence allow for reference passing?

OK.  That's a bit off-topic; just curious.  Sounds like I can use  
wither "&foo" or "foo" so long as it's "const".  Good.  I'll try that  
tomorrow.  Hopefully my problem was elsewhere.

> > 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.

What I'm interested in is:

        const std::vector<std::vector<int>>  &foo;

The receiving block will do error checking, but otherwise there will  
be no changes to the data.  Any SWIG users out there who could offer  
advice?  I'll try the SWIG list & docs too, tomorrow.

> > 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.

Yes yes, standard C++ ;-)  In the context of how SWIG interprets the  
declarations for the friend method(s), that's my question.  I tried  
having the last 3 arguments of the friend method have defaults (of 7,  
so 4 required, 3 optional), but then the instantiation from Python  
doesn't work.  Could be that I messed up something else along the  
way, but this was the last change I made (removing the 3 default  
values) and -poof- things worked again.

> 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.)

Ah, so just name the friend method differently than that of the  
"default" friend method?  Hmmm, I'll try that tomorrow when I have a  
chance.  Clearly for a given C++ class, the constructor names will be  
the same but with different arguments ... so the difference has to  
come in the friend naming.  I would guess it would require it's own  
GR_SWIG_BLOCK_MAGIC stuff too, with the different friend name?