Re: [Discuss-gnuradio] Proper block inheritance

[Tom Rondeau]

On Wed, Sep 11, 2013 at 6:44 AM, Marcus Müller <address@hidden> wrote:
> 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)?


Nemanja,

Yes, Marcus is right, this probably isn't what you want to do. We have
some blocks that have multiple parent classes, but there is only one
path from gr::block and the other parent class has completely
different responsibilities.

What you'll probably want to do is derive a new class from
gr::sync_block (or whatever) and then derive your actual block from
your new class, overloading the functions as needed in that new class.


-- 
Tom
Visit us at GRCon13 Oct. 1 - 4
http://www.trondeau.com/grcon13


> 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ć