Re: [Discuss-gnuradio] Code re-use in blocks / C++ inheritance with gr::sync_block

[Marcus Müller]

Hi Sylvain,
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++,
> http://pastebin.com/raw.php?i=cDWQQwHn
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
> gr::sync_block's methods.
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, 
base_sink_c.
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
> headers)
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....

Cheers,

Marcus