I’ve always wondered why GNU Radio didn’t use C++ templates for gr-
blocks (see e.g. the ‘gengen’ subdirectory in gnuradio-core), since
they generally result in much less written code. Might partly be
that SWIG only “recently” (as of 1.3.12 or so) added C++ templates to
its bag of tricks? Also might be that the SWIG interface is
challenging at its best, let alone with something as complex as C++
template expansion / instantiation?
Last week I hacked through both the C++ and SWIG necessities to get
template C++ gr-blocks to expand (instantiate) correctly into shared
libraries that work correctly with both Python and C++. After much
fussing, I wrote a SWIG macro (%define), similar to
“GR_SWIG_BLOCK_MAGIC”, but for template C++ class expansion into
uniquely named GR blocks. While the macro might not work for
everyone (or it might, testers would be appreciated), and maybe it’s
a bit ugly to read, the steps in it make sense according to the SWIG
documentation.
If anyone is interested I can provide more information. - MLD
On Wed, Aug 29, 2007 at 10:48:07PM -0400, Michael D. wrote:
libraries that work correctly with both Python and C++. After much
fussing, I wrote a SWIG macro (%define), similar to
“GR_SWIG_BLOCK_MAGIC”, but for template C++ class expansion into
uniquely named GR blocks. While the macro might not work for
everyone (or it might, testers would be appreciated), and maybe it’s
a bit ugly to read, the steps in it make sense according to the SWIG
documentation.
If anyone is interested I can provide more information. - MLD
Great!
Can you point us to the code, and show for example, how you’d handle
gr_sig_source*?
Thanks,
Eric
On Wed, Aug 29, 2007 at 08:23:12PM -0700, Eric B. wrote:
template C++ gr-blocks to expand (instantiate) correctly into shared
Great!
Can you point us to the code, and show for example, how you’d handle
gr_sig_source*?
Also, if you’ve got time, can you see if you can figure out how
to handle the accumulator type inference in
filter/generate_gr_fir_XXX.py?
There’s probably a way (template metaprogramming from hell?), but beats
me.
Thanks,
Eric
Another point: Each template type must be individually instantiated
in the code. This is not automated in any way except for the SWIG
MAGIC stuff, but some parts of it probably could be automated via
#define’s or something like that. All of this means that instead of
defining some code (“XXX”) and having the Makefile expand it,
everything is in the code instead … all of the instantiations,
whether SWIG or C++. This makes it simple to change the code for new/
other template types (copy, paste, replace-string), but it’s not as
automated as that which the Makefile provides (via a list of
expansion types). It’s a trade-off; somewhere a list has to be put
together to handle what the expand or instantiate.
On Aug 29, 2007, at 11:23 PM, Eric B. wrote:
Can you point us to the code
I’ll post the code for demo_sig_source instead once it compiles and
works, most likely later today (for me, now, since I’m up way too late).
, and show for example, how you’d handle
gr_sig_source*?
Since the X instantiations are ‘s’, ‘i’, ‘f’, and ‘c’, and the only
method that’s non-standard is “::work”, and there is only one
“complex” type that I’ve ever seen used in GNU Radio (“gr_complex”),
then I’ll write the ‘default’ code for non-complex types since there
are many more of them, and overload it for “gr_complex”
specifically. The rest will be about the same as my current code for
template expansion since all the other methods are common to all
output types. This is the same method used for modifying the base
name of the block (overloading a “make_name” method, one for each
desired template type). - MLD
On Aug 30, 2007, at 1:09 AM, Michael D. wrote:
On Aug 29, 2007, at 11:23 PM, Eric B. wrote:
Can you point us to the code
I’ll post the code for demo_sig_source instead once it compiles and
works, most likely later today (for me, now, since I’m up way too
late).
< http://www.nd.edu/~mdickens/GNURadio/demo_sig_source/ >
I created the template C++ / SWIG interface, updated the sig_source
class to use templates and SWIG MAGIC, and updated the “qa” test for
“sig_source” to use my updated code instead of "gr"s code. My code
passes all of the qa-tests that the “gr” code passes.
You can get the gist of how to do all of this from this example.
Expanding to include other templates is straight forward - though
possibly adding even more template C++ code to deal with the added
number of explicit expansion possibilities: suppose there are 4 types
per template [s, i, f, c]; then using 1 template results in 4
possibly explicit expansions; 2 templates in up to 16; 3 in up to
64! While not all combinations will be used or even desirable,
clearly this could be an issue.
Please note the comments about automating template expansion and such
(in the .h and .cc files). There’s probably a quick and easy way to
do this, but I wanted to get the code out. I’ll think about how to
clean it up so that the expansion is more automated and less
difficult to the user. - MLD
Michael D. wrote:
I’ll post the code for demo_sig_source instead once it compiles and
works, most likely later today (for me, now, since I’m up way too late).
< http://www.nd.edu/~mdickens/GNURadio/demo_sig_source/ >
This is clearly a better approach than what we have now, at least in
principle.
We really should look at migrating this direction for 3.2.
–
Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com
On Aug 29, 2007, at 11:33 PM, Eric B. wrote:
Also, if you’ve got time, can you see if you can figure out how
to handle the accumulator type inference in filter/
generate_gr_fir_XXX.py?
There’s probably a way (template metaprogramming from hell?), but
beats me.
I will look into this. It’s a bit more complicated than the usual
template concepts (i.e. for most if not all of the blocks in
‘gengen’), and will thus take me more time to parse and understand
what’s really going on. I’ll get back in a bit. - MLD
Johnathan C. wrote:
principle.
We really should look at migrating this direction for 3.2.
Do I ever agree. This will make it much easier for several things I
will have going for the next several months.
Bob
–
Robert W. McGwier, Ph.D.
Center for Communications Research
805 Bunn Drive
Princeton, NJ 08540
(609)-924-XXX-4600
(sig required by employer, remove X’s for phone #)
On Thu, Aug 30, 2007 at 12:44:04PM -0400, Michael D. wrote:
what’s really going on. I’ll get back in a bit. - MLD
Thanks!
Eric