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 <vlasi...@gmail.com
<mailto:vlasi...@gmail.com>> 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 <j...@joshknows.com
<mailto:j...@joshknows.com>> 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
Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--
Nemanja Savic'
--
Nemanja Savic'
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
