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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
