But why would you code for an exact match if you don't need to? If you are resetting the counter like I suggested, be it by bitwise mask or otherwise, the value should be reset anytime it goes above the designated value. So compare the two: if (counter == value) if (counter > value) Which is more robust ?
It's like the old rule that you should not compare to True, rather you should compare to False, except in this case the counter is more easy to be set outside of range (a Boolean has to be from an outside source or a union field to be neither True nor False). The thing is in the future tracking down a little bug because of an == versus an > or an >= can be really hard to spot. (way harder than having our debug display set as hex etc) |-----Original Message----- |From: [email protected] [mailto:ozdotnet- |[email protected]] On Behalf Of DotNet Dude |Sent: Tuesday, 18 May 2010 2:12 PM |To: ozDotNet |Subject: Re: How To do something every so often | |Dylan never said it was multithreaded... that would have been a |critical piece of info and I'm sure he wouldn't leave it out. He said |"very simple little console app" which rules out multithreading. :p | | |On Tue, May 18, 2010 at 2:04 PM, Bill McCarthy <[email protected]> wrote: |> Possibly, but if you make the code multithreaded you'd have to use an |> interlocked increment. Use of a >= or a higher order bit bit-mask means you |> don't have to lock as such (if you aren't worried about the exact count) |> |> |-----Original Message----- |> |From: [email protected] [mailto:ozdotnet- |> |[email protected]] On Behalf Of DotNet Dude |> |Sent: Tuesday, 18 May 2010 1:21 PM |> |To: ozDotNet |> |Subject: Re: How To do something every so often |> | |> |Wouldn't this be enough? |> | |> |counter+=1; |> |... |> |if (counter == 10000) { |> | ... |> | counter = 0; |> |} |> | |> | |> |On Mon, May 17, 2010 at 1:30 PM, Dylan Tusler |> |<[email protected]> wrote: |> |> I was just writing a very simple little console app to move data from one |> |> file to another (under certain conditions) and I thought it would be |> |> beneficial if the output gave some feedback that something was |happening. |> |> |> |> So, for each file, for every 10,000 lines processed, I put a "." out via |> |> Console.Write |> |> |> |> Seems simple enough, but I was wondering how you would go about |> |determining |> |> that you got through 10,000 lines? |> |> |> |> Here was my approach: |> |> |> |> int counter=0; |> |> |> |> while ((line = fs.ReadLine()) != null) |> |> { |> |> // do stuff - snipped |> |> counter++; |> |> if ((int)(counter/10000)*10000 == counter) |> |> { |> |> Console.Write("."); |> |> } |> |> } |> |> |> |> This works fine in my application, but I was wondering what different |> |> approaches were available, especially considering there is a bit of |> wasted |> |> math here, seems like it could be costly for a very long running process. |> |> (In my situation, the app will be processing many millions of rows of |> data, |> |> so small savings could add up to a big net saving.) |> |> |> |> Cheers, |> |> |> |> Dylan Tusler |> |> |> |> |> |> |> |> |> ---------------------------------------------------------------------------- |> --------------------- |> |> To find out more about the Sunshine Coast Council, visit your local |> council |> |> office at Caloundra, Maroochydore, Nambour or Tewantin. Or, if you |> prefer, |> |> visit us on line at www.sunshinecoast.qld.gov.au |> |> |> |> This email, together with any attachments, is intended for the named |> |> recipient(s) only. Any form of review, disclosure, modification, |> |> distribution and or publication of this email message is prohibited |> without |> |> the express permission of the author. Please notify the sender |> immediately |> |> if you have received this email by mistake and delete it from your |> system. |> |> Unless otherwise stated, this email represents only the views of the |> sender |> |> and not the views of the Sunshine Coast Regional Council. |> |> maile 3_0_0 |> |>
