|
From: | Terry Barnaby |
Subject: | Re: [Discuss-gnuradio] Using GnuRadio API from C++ |
Date: | Thu, 10 Nov 2005 09:19:44 +0000 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.7.12-1.3.1 |
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 TerryOK. 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
[Prev in Thread] | Current Thread | [Next in Thread] |