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) 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?) > - 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 -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association
pgpLAVfch06dO.pgp
Description: PGP signature
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
