[Top][All Lists]

[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


> 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++,

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]