[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 11:55:20 +0200
> this is yet another incarnation of the diamond problem I discussed with
> Your glfw_.._impl is a double indirect subclass to base_sink_c:
Yeah and that's what the 'virtual' are for in the inheritance tree.
And if you look at the resulting tree according to C++,
you have in the first path :
gr::fosphor::base_sink_c (0x7f7a522eebc8) 0 nearly-empty virtual
and in the second path, it ends with :
gr::fosphor::base_sink_c (0x7f7a522eebc8) alternative-path
with the same address and "alternative-path" leading me to believe it
did the right thing and pointed to the first instance of it rather
than create a second one.
> 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.
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
> 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