|
I remember investigating one application that tried to jump to an invalid location. That app was innocent. Some other code used COMMON to reach what happened to be that program's current memory location, re-wrote the computer instructions including the said jump statement. The app was just running it's instructions when all of a sudden it wasn't their instruction set anymore.
|
|
|
|
|
#define true false
Never trust those booleans!
|
|
|
|
|
IEnumerable<int> finalMarkRange = Enumerable.Range(73,2);
if(finalMarkRange.Contains((int)Math.Round(finalMark,MidpointRounding.AwayFromZero)))
{
...
}
|
|
|
|
|
That's really much better to understand than
if (finalMark < 74.5 and finalMark >= 72.5) { ... }
Get rid of such complicated math!
|
|
|
|
|
and much slower to execute...
I'm brazilian and english (well, human languages in general) aren't my best skill, so, sorry by my english. (if you want we can speak in C# or VB.Net =p)
|
|
|
|
|
I'm guessing there's a whole series of such things?
|
|
|
|
|
I think his & key was not working other wise he would have used a && to do it. poor guy.
|
|
|
|
|
I recently started working for a new company and found quite a few situations like this:
Thread m_thread = new Thread(new ThreadStart(GenerateTimeLineImage));
m_thread.Start();
m_thread.Join();
I'm no expert on mulithreading but there are so many different (not just brainless copy-paste) of code like that, that it made me wondering is there some hidden magic behind that code that I'm not aware of.
So, what's the difference between that and
GenerateTimeLineImage();
besides obvious performance loss due to creating a pointless thread?
|
|
|
|
|
I dont think you missed the magic here. I think, you are right that the thread is pointless in this sample.
You should speak to the author of this code if hes still in your company.
|
|
|
|
|
He's not, I'm his replacement...
|
|
|
|
|
That's why you are replacing him - you can see it.
|
|
|
|
|
That explains everything
|
|
|
|
|
Yes you are right that this code works synchronously albeit using a separate thread. The coder needs to stand in the corner with a dunce cap on.
Cheers!
"With sufficient thrust, pigs fly just fine."
Ross Callon, The Twelve Networking Truths, RFC1925
|
|
|
|
|
I think that makes sense in a WinForms app -- if GenerateTimeLineImage takes a bit of time, which seems likely.
|
|
|
|
|
It's not a winforms app, but even it were, it still don't make sense. GenerateTimeLineImage is a heavy function but it would still block the UI thread (if that's why you mentioned WinApp) because of the m_thread.Join() there.
|
|
|
|
|
No, not the least. In that case the UI thread would be waiting until the other thread is finally done. Meanwhile the UI would not respond, just as if the task had been done on the UI thread itself.
At least artificial intelligence already is superior to natural stupidity
|
|
|
|
|
Thread.Join Method
Blocks the calling thread until a thread terminates, while continuing to perform standard COM and SendMessage pumping.
|
|
|
|
|
Does this actually work? (I.e. do your event handlers get called, does the window repaint properly, etc?)
|
|
|
|
|
No. Try the following code - The ui blocks for 10 seconds - i am sure.
private void button1_Click(object sender, EventArgs e)
{
Thread m_thread = new Thread(new ThreadStart(GenerateTimeLineImage));
m_thread.Start();
m_thread.Join();
}
void GenerateTimeLineImage()
{
Thread.Sleep(10000);
}
|
|
|
|
|
OK, I sit corrected. However, maybe the developer often needs to do that with several items:
Thread t1 = ... ; t1.Start() ;
Thread t2 = ... ; t2.Start() ;
...
Thread tn = ... ; tn.Start() ;
Join (t1 ) ;
Join (t2 ) ;
...
Join (tn ) ;
and uses this as a general pattern. :shrug:
In which case I might consider a method that takes a collection of delegates:
private static void
InvokeAll
(
params System.Threading.ThreadStart[] Items
)
{
/* Null checking :D */
System.Threading.Thread[] thread = new System.Threading.Thread [ Items.Length ] ;
for ( int i = 0 ; i < Items.Length ; i++ )
{
if ( Items [ i ] != null )
{
thread [ i ] = new System.Threading.Thread ( Items [ i ] ) ;
thread [ i ].Start() ;
}
}
for ( int i = 0 ; i < thread.Length ; i++ )
{
if ( thread [ i ] != null )
{
thread [ i ].Join() ;
}
}
return ;
}
(Untested)
|
|
|
|
|
The good man heard that he was supposed to start a thread when some task takes longer. He did that. Nobody told him what to do once he got the thread going.
Good soldiers who obey every order rarely make good thinkers
At least artificial intelligence already is superior to natural stupidity
|
|
|
|
|
The only reason I can imagine doing something like that is if there is a requirement that GenerateTimeLineImage() execute on a non-UI thread, and yet be synchronized to the UI thread that requests the operation.
There are plenty of the opposite circumstance (requesting a UI operation from a worker thread), but this sounds strange.
Software Zen: delete this;
|
|
|
|
|
Or perhaps to protect the UI thread from Exceptions?
|
|
|
|
|
Or perhaps there is another thread that somehow manages these extra threads (e.g., abort them if they take too long).
|
|
|
|
|
The Thread object is local so I don't think this can be happening.
|
|
|
|