Eric Blossom wrote:
On Mon, Oct 03, 2005 at 02:58:36PM +0100, Terry Barnaby wrote:
Hi Eric,
Thanks for the info.
I don't have an aversion to Python, we use it quite a lot. But our
current project involves production of a real-time 24/7 semi-embedded
system. It is good for ease of development, testing, installation and
maintainance to have small amounts of code and as few dependancies
on other sub-systems as possible. In this case Python adds a big
layer of complexity to the final system.
Physical RAM may be cheap but producing/maintaining a real-time system
that has a lot of code is not :)
I will have a look to see if we can use the lower-level 'C++' signal
processing classes in our system directly.
Cheers
Terry
OK. Please let us know how it goes.
Eric
Just a quick update on this.
I have managed to get a basic C++ only interface to GnuRadio working.
For my use all I needed to do was re-implement the flow_graph class
in C++ rather than Python. This has enabled me to create a C++ only
implementation that works for me.
My current C++ flow_graph class is not complete, but it seems that it
would be reasonbly easy to fully implement this in C++ rather than
Python. If GnuRadio moved the flow_graph class to C++ this would allow
the core of GnuRadio to be used directly from C++ ...
One little point is the forced use of the Boost shared_ptr to create
GnuRadio objects (Constructer is protected). It would make the C++
API cleaner if it was possible to create the Objects directly rather
than only via a Boost shared_ptr. Is there any issues in allowing
the Objects to be created and managed by the application ?
Cheers
Terry
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
