Re: [Discuss-gnuradio] Proper block inheritance

[Marcus Müller]

Hi Nemanja,

I don't think deriving from two blocks will work; C++ allows you two have multiple superclasses, sure enough, but what deriving from two subclasses of the same base class (at least gr::block in this case) will give you is the so-called diamond problem. As an example let's say you've got something of the like:
  class Nemajas_Block public gr::awesome_block, gr::coolness_block;
with both awesome_block and coolness_block not being abstract classes (thus, you can create instances of awesome_block and coolness_block).
As a matter of fact, an instance of Nemajas_Block will *contain* the data of an awesome_block and the coolness_block, and those two each contain an own gr::block object.*
So there's two basic_block s that represent your instance of Nemajas_Block, of which only one will be connected... I haven't tried this, but I'd think this will lead to the GR runtime telling you to connect the unconnected parts.

So long answer short: No, I don't think there is an example where a block is derived from two isolated working blocks, because that's not a good idea.
There are, however, examples, where, using the virtual inheritance method, a block is derived from a base block and gr::block directly; take gr::analog::pwr_squelch_ff. Look closely where they use the virtual inheritance method!

I'm not quite sure however, why, for your particular problem, you can't take either a) the gr::blocks::file_sink way (inherit from gr::block and from a non-block class) or b) just put your algorithmic implementation into subclasses of a common (non-block) deframer_algorithm_base_class, and have your block hold a pointer to an arbitrary one of those, calling that to deframe when needed.

Hope that was helpful
Marcus

*unless inheritance was defined as ":(public|private|protected|) virtual superclass" all the inheritance chain down, but from looking at the source, I'd think this is not usually the case (especially not for sync_block).

Am 11.09.2013 10:41, schrieb Nemanja Savic:

Actually my question is: is there any example where some block is derived from two other blocks (for example from two sync blocks)?

On Tue, Sep 10, 2013 at 12:45 PM, Nemanja Savic <address@hidden> wrote:

Thank you Josh. At the moment I wanted to make this as simple as possible. My idea was to make a new class(block type) and to make my impl class inherit that class also. In that new class I would store message port subscription and a method for sending message that deframer received valid message. The problem is i can't really figure out how to make a the new class that will be used only to be inheritted by my deframer block.

Something simillar is done with filter blocks in gnuradio, there are few classes declared in fir_filter.h and other filters inherit that class.

Cheers,
Nemanja

On Fri, Sep 6, 2013 at 1:07 AM, Josh Blum <address@hidden> wrote:

On 09/05/2013 02:12 AM, Nemanja Savic wrote:
> HI all guys,
>
> I have 3 different packet deframers, and now I would like them to be able
> to send a message to a certain block about correct packet reception. In
> order to do that I want to make some "phantom" block that will have message
> out port.

Are you looking to have a sort of control block that can apply
configuration settings to these packet deframers? Either once at
init-time or at runtime based on some conditions? If so, this also might
make sense for you:

In GRAS, your deframers would register calls for configuring packet
reception:
https://github.com/guruofquality/gras/wiki/Codeguide#method-registration

In the top block, when you connect flows, you can also register the
blocks into a tree. The control block could then find the deframers at
runtime and apply new settings dynamically:
https://github.com/guruofquality/gras/wiki/Codeguide#wiki-zero-configuration


Its all GRC friendly and thread safe. You could do this with messages
too, it really depends what works best or makes the most sense. Anyway,
I have just been thinking about this kind of stuff and I wanted to share.

-josh

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

--
Nemanja Savić

--
Nemanja Savić

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio