hansenjo
commented
6 years ago Thanks Bob, but I am getting very confused now. It looks like there are three definitions of data_type_def now:
1) member variable of PipeliningModule 2) member variable of Fadc250Module, which inherits from PipeliningModule, therefore masking the member variable in PipeliningModule 3) static variable in PipeliningModule::SplitBuffer, which again masks the member variable
Item (3) was the original problem, but it's still there. I think this is an oversight, and that definition should just be deleted.
Since data_type_def is used both in PipeliningModule::SplitBuffer and Fadc250Module::DecodeOneWord, you have to decide: is this the same data, or different data?
If the same, delete the member variable definition in Fadc250Module. If different, data_type_def needs to be renamed to something else in either PipeliningModule or Fadc250Module.
Could you please check what's appropriate here, make the changes, and submit a new pull request?
Sorry for being a pest, but the way it is now, I think it's even worse than before ....
Thanks, Ole
rwmichaels
Fixes that address the original issue #151 (data_type_def not necessarily defined) and the related discussion about why data_type_def was static (should not be), and about the need to pass the data buffer as a constant reference in SplitBuffer. All pretty easy to fix, but it took me awhile to test it because my test stand had been upgraded to CODA 3.07, which opened up a whole other can of worms.