I am unable to print from C++ code in gnuradio. I have tried various
combinations of included libraries and different types of print statements
in my C++ code. However, nothing that I have tried yet (see some attempts
below) has let me see any output from the command terminal (where my printed
python output appears). I found an old response from Eric B. for a similar
problem, but the offered solution did not work for me either.
// #include <iostream> // DAK
#include <cstdio>
// #include <stdio.h> // DAK
// #include <iostream> // DAK
#include <cstring>
....
fprintf(stdout, "\nTEST");
fprintf(stderr, "\nTEST");
printf ("\nThis is a test");
fprintf(stderr, "Samples Processed: %d\n", d_processed), fflush(stderr);
During the make/make install process (executed from the /src and /src/lib
directories after my experimental changes; not sure where I'm supposed to do
this). I see errors if my C++ syntax is not correct, so presumably my
changes are actually being compiled and I also see the corresponding object
file times changing appropriately. There could well be a problem with the
importing of modules in python or C++ and/or my directory structure or
paths.... sort of why I need the print statements to work in the first
place.
I don't claim to understand the hierarchy of python/swig/c++ calls or the
autotools processes yet. My basic task is to figure out the execution
progress and sequencing of some routines written by others (which are a bit
more complicated than the one in D. Shen's tutorial). I want to understand
the control flow for some ucla 802.15.4 extension code to gnuradio,
specifically in the receive direction.
In general, how should/could standard I/O work out of a C++ program through
SWIG into python? Could someone tell me what is *supposed* to work (i.e.
maybe the pertinent #include and (f)printf statements. Alternatively, maybe
someone could give alternatives to my primitive approach for understanding
python/C++ program control flow and calling structure? I have tried using
the python interpreter and manually listing modules and module paths after
each encountered import statement; pretty tedious.
Presumably, there could be issues if C++ print statements get executed at
the same rate as RF data is processed... but right now being swamped by
print statement output from the signal processing code would be a welcome
problem!
Thanks, David
--
View this message in context:
http://www.nabble.com/Printing-from-c%2B%2B-code-tp25891709p25891709.html
Sent from the GnuRadio mailing list archive at Nabble.com.
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
