[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Code re-use in blocks / C++ inheritance with gr::
From: |
Sylvain Munaut |
Subject: |
Re: [Discuss-gnuradio] Code re-use in blocks / C++ inheritance with gr::sync_block |
Date: |
Tue, 22 Oct 2013 11:55:20 +0200 |
Hi,
> this is yet another incarnation of the diamond problem I discussed with
> Nemanja:
> http://lists.gnu.org/archive/html/discuss-gnuradio/2013-09/msg00150.html
>
> Your glfw_.._impl is a double indirect subclass to base_sink_c:
> glfw_sink_c_impl->glfw_sink_c->base_sink_c
> glfw_sink_c_impl->base_sink_c_impl->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++,
http://pastebin.com/raw.php?i=cDWQQwHn
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
gr::sync_block's methods.
> 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)
Cheers,
Sylvain