On Mon, Sep 21, 2015 at 6:40 AM, bob wole <bnw...@gmail.com> wrote:
> I am studying the code of correlate_access_code_bb_impl.cc for
> understanding its working. I see that the block is derive from "block"
> class of gr as written in correlate_access_code_bb_ts.h file
>
>
> class DIGITAL_API correlate_access_code_bb_ts : virtual public block
>
>
> I read earlier that blocks derived from "block"/"gr::block" should
> implement forecast() method, but I did not see any implementation of
> forecast() in code of correlate_access_code_bb_impl.cc.
>
> Can somebody please tell me why ?
>
> --
> Bob
>
First, you have a misunderstanding of the header/source relationship. There
are a number of correlate* blocks in GNU Radio (and an unwritten plan to
organize them better in the future). The correlate_access_code_bb is one
block, and this is a gr::sync_block. The correlate_access_code_bb_ts is
another block, and this one is a gr::block.
If you look at the code for block.cc, you'll see it implements a forecast
function already:
void
block::forecast(int noutput_items, gr_vector_int &ninput_items_required)
{
unsigned ninputs = ninput_items_required.size ();
for(unsigned i = 0; i < ninputs; i++)
ninput_items_required[i] = noutput_items + history() - 1;
}
That means that any block that derives from gr::block gets this behavior,
which tells the scheduler that given noutput_items, the block needs this
many input items to produce that output amount. This is a satisfactory
condition for many blocks, so no, you don't /have/ to overload forecast in
your derived block if this condition meets your block's behavior.
Tom
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
