[mythtv] Re: [mythtv-commits] Re: Ticket #339: Simplify Tuning
ijr at case.edu
Thu Sep 22 13:12:43 UTC 2005
On Thursday 22 September 2005 02:21 am, Daniel Kristjansson wrote:
> On Thu, 2005-09-22 at 05:32 +0000, MythTV wrote:
> > Comment (by ijr):
> > Heh. Sorry, but... The tv_rec changes are pretty iffy, I think. I
> > don't understand why you like replacing member variable accesses with
> > function calls. It's not any easier to read, IMO, and liable to make
> > things slower if the compiler doesn't decide those functions get inlined.
> If the function is in the header file, I can't think of any compiler
> which wouldn't inline them. But I believe the ones you are questioning
> are actually cast wrappers, no?
Yeah, stuff like IsCardType. I don't think that's any different than old
comparison. If anything, it's less obvious since I had to go check
IsCardType to see if it was doing anything non-obvious.
> Some of the functions, like in the whole TuningState thing, are
> for debugging purposes only. Basically they make it easy for me
> to add a verbose macro to print out the value when it is examined
> or changed. I'm planning to collapse TuningState into TVRec when
> I'm further along. I don't need half those variables except for
> preliminary debugging.
> TVRec is in a rough state right now.
Yeah, just making sure now so it's ok later on, since I'm going to be in there
for other stuff soon. =)
> I didn't like them much when I first saw Jacob using them in his code,
> but it is almost impossible to figure out what is going wrong with
> multiple recorders without some kind marker indicating which recorder
> is spitting out which info. In this case I made it spit out the
Yeah, but that could be added in a different way, though that doesn't use
custom macros for every different file.
> The whole tuning in RunTV is just busy waiting at the moment, but
> I'm planning to use things like the signals from the SignalMonitor
> to trigger trips through HandleTuning().
More information about the mythtv-dev