From time to time I find some behavior that I cannot really neither explain as correct nor as incorrect. Best description would be peculiar.
Let’s take simple code:
staticvoidMain(){int x =(int)double.PositiveInfinity;
Debug.WriteLine(x);}
This will cause compile error “Constant value ‘1.#INF’ cannot be converted to a ‘int’ (use ‘unchecked’ syntax to override)” and personally I view this as correct behavior.
Let’s complicate things a little:
staticvoidMain(){double posinf =double.PositiveInfinity;double neginf =double.NegativeInfinity;int x =(int)posinf;int y =(int)neginf;
Debug.WriteLine(x);
Debug.WriteLine(y);}
Here I expected one nice runtime exception. However, I was greeted with -2147483648 as a result for both positive and negative infinity. This I did not expect.
My personal opinion here is that this operation should throw exception. I cannot see any sound reasoning for converting infinity to any finite number. It is called infinity for a reason!
However, I do notice that most of languages choose to have this conversion pass. Unfortunately for C# they (e.g. Java) opted for slightly different behavior.
Java converts negative infinity in same manner C# does but positive infinity gets converted to 2147483647. This may not seem like much, but this at least enables positive infinity to be larger than zero which seems mathematically sound to me (if we ignore all that infinity thing :)).
My personal opinion here is that exception should be thrown. Only thing that this conversion can lead to is data corruption - and this is not a good thing.
P.S. I reported this as an issue to Microsoft. I am really interested how they view this situation.
LogCat is quite good thing to look at when program goes haywire since it usually shows both system and developer’s own log messages.
If you are trying to debug your Android program inside of Eclipse and you cannot see your custom log message, fixing it might be as simple as going to DDMS perspective and selecting your current device (whether real or simulated).
LogCat window displays only messages from device in focus and that might not be device you are currently debugging.
I consider Visual Studio 2010 an improvement to Visual Studio 2008. However, it had few annoying issues.
One was making find box wider and wider and that was solved few weeks ago via patch.
Another one was need to scroll context menu although there was enough place on screen. Finally patch for that issue is here. For this patch to work properly you also need another WPF patch.
This is quite a collection of patches - 1, 2 and 3. Once these are installed Visual Studio 2010 suddenly becomes even better environment.
Creating your own thread is not something that I do lightly. There are so many alternatives these days where framework does “dirty job” for you.
However, sometime making your own thread is way to go. I found that mostly I use same code in order to cancel it.
Idea is creating ManualResetEvent that we can check fairly quick from thread loop. Once that event switches it’s value to true, our thread should terminate.
privateManualResetEvent _cancelEvent;privateThread _thread;publicvoidStart(){
_cancelEvent =newManualResetEvent(false);
_thread =newThread(Run);
_thread.IsBackground =true;
_thread.Name ="EntranceBarrier";
_thread.Priority = ThreadPriority.AboveNormal;
_thread.Start();}publicvoidStop(){
_cancelEvent.Set();while(_thread.IsAlive){ Thread.Sleep(10);}//wait until it is really stopped}bool IsCanceled {get{return _cancelEvent.WaitOne(0,false);}}voidRun(){while(!IsCanceled){//some codeif(this.IsCanceled){return;}//some code}}
P.S. This will terminate thread gently and it only works if event is checked often. If you have code that is waiting for system event, this is not solution for you.