[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Code re-use in blocks / C++ inheritance with gr::
Re: [Discuss-gnuradio] Code re-use in blocks / C++ inheritance with gr::sync_block
Tue, 22 Oct 2013 12:27:25 +0200
Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
this is getting really interesting :)
On 10/22/2013 11:55 AM, Sylvain Munaut wrote:
Yeah and that's what the 'virtual' are for in the inheritance tree.
And if you look at the resulting tree according to C++,
I totally agree! So, only one basic_block instance, most probably.
So I dived into gnuradio-runtime/lib/flowgraph.cc, specifically looked at
check_valid_port (lines 137ff);
could you verify that your program does not output something like "port number X
exceeds..." or the like upon termination?
If you correctly called the chain of superconstructors, that shouldn't happen
if you correctly set your io_signatures.
So: one of glfw_sink_c or base_sink_c must not inherit from gr::basic_block.
The issue there is that the exposed interface glfw_sink_c must have a
path to gr::sync_block visible to the user.
It has, by either inheritance detour :) all your inheritance is public.
And I think that base_sink_c_impl also need a path to gr::sync_block
in it's hierarchy because it's the one actually implementing its
virtual methods (start/stop/work/...) and also using some of
That's what I thought; therefore, I suggested moving the code shared among the
glfw_sink_c_impl and the base_sink_c_impl to the common super class,
If you do not want your flowgraphs to use base_sink_c, there is no sense in
having base_sink_c_impl as a proxy between base_sink_c and glfw_sink_c_impl.
Anyway, even if you use that intermediate class, you inheritance will become a
path without the dreaded inheritance diamond.
personally, I'd just not let glfw_sink_c_impl inherit from base_sink_c_impl,
and move the common stuff directly to base_sink_c.
The problem I have with this is that I must expose a bunch of stuff in
the public header that I don't want to.
base_sink_c_impl has plenty of private method and members, none of
which the "user" should see (ie. not be installed in the public
I think that's the point of private and protected members, you shouldn't have
to go to the total extreme of hiding everything away in an impl, if you plan to
inherit from that impl later....