On Tue, Jun 26, 2012 at 4:39 AM, Martin Braun (CEL) <martin.br...@kit.edu> wrote: > Hi Johnathan, > > and thanks for the answers! > > On Fri, Jun 22, 2012 at 09:15:53AM -0700, Johnathan Corgan wrote: >> - Can you please comment on making *all* blocks virtual and totally >> separating the DSP from the block definition? Is this simply taking the >> separation to a new 'extreme', or are there other reasons? Is it still >> possible to make the block non-virtual and put everything inside? >> >> I don't quite follow your question. Could you elaborate? > > Sure: in the old system, the actual blocks are directly derived from > gr_block (or gr_sync_block etc.). Now, only virtual blocks are derived > from gr_block (and exported). Then, in 'lib', the virtual blocks are > further derived into the impl-blocks, where the DSP is done. > > This comes with a slight cost in overhead: (e.g., extra .h-files, and > any methods which are exported need to be declared first virtual, then > derived and defined). > My questions are > 1) Where are the benefits of this approach? (The simple three-line swig > files seemed to work without the additional abstract blocks)
Yeah, but I think it's very little cost in the overhead. This way, we control exactly what get's exported, which is why we can do the SWIG files like that. That's one benefit. The other benefit is that we are free to change the implementation behind the scenes and no one using it ever need be the wiser for it. It will help us create a binary interface to the libraries that we can rely on. We're not quite there with providing an ABI compatibility, but this comes closer. > 2) If I don't like this method, does anything stop me from making the > block derived directly from gr_block non-virtual and putting the DSP > inside that block (I assume at the very least I have to use the old > SWIG_MAGIC function?) No, we haven't removed any ability to do that (yet). The SWIG magic that you mentioned will likely be replaced once we've converted everything over to the new way. At that point, you'll either need to handle it yourself of switch to the new standard. >> - By which logic is mmse_fir_interpolator_cc.cc not a '_impl.cc' file? >> >> It's not actually a block, and the header isn't exported. It is code used >> internally by the fractional_interporlator_cc and _ff blocks, which *are* >> impled. > > Obviously I misunderstood the usage of the _impls: I assumed anything > that wouldn't necessarily have to be put inside a block would be an > impl. > > Cheers > MB Yes, only blocks have a public header and private implementation. Other classes and files that do non-GR block implementations of algorithms, like fir_filter, pm_remez, and others are not done this way so that they can be exported and used as primitives or base classes for other components and projects. Tom _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
