ERROR_SUCCESS. This macro would be familiar to all those who have done some programming in WIN32. It is the output of the GetLastError() function to check the thread's last error state when no error has occurred. Weird, isn't it? I mean, if it is a success, then why is it marked as an error in the macro?
This is one example of a badly made API. APIs are considered bad when programming in them becomes non-intuitive. Software is said to be bad (or said to suck) when it seems counter-intuitive to the user. There is one very simple example of this.
Start notepad. Type in any text. Click on close. The message that you see is:
This makes no sense to me as a user. Of course, the programmer follows the approach that he creates a temporary file called
Untitled, and in that file he allows the user to make all his changes. But how am I, as a user to understand that?
A similar disconnect occurs even between two different programmers. That is why it takes a whole lot of effort to make a programme using a different API than what one is used to. But by far, the most difficult and non-intuitive API that I have used is the WIN32 API.
CreateThread() looks pretty intuitive as a function to create a thread. But there is a deep catch. If the programmer uses any of the C++ stdlib functions, then CreateThread shall lead to memory leaks. Now this sure is not clear from the function description. Similarly, to end a thread in a clean fashion, the programmer must make the thread return a value. If the thread is forcefully terminated by means of the TerminateThread() function, then the destructors for the objects within the thread are not called, which causes the thread to waste memory. Further, there is no automatic garbage collection, as there is with Java or C#. Perhaps this shall tell why it does not make sense to forcefully terminate any programme via the task manager. If the programme does not have a good garbage collection mechanism, then the programme shall eat up memory and waste space.
Another annoying thing I found was about the way any object must be created/used. In WIN32, there may be a large number of errors that may occur when any object is used. The error catching codes go larger than my basic code. So it happens that my code for a simple multi-threaded application would be around 50 lines, around 100 lines get added in handling errors. Well, what happens if you miss out any particular error? In that case, you are a bad programmer.
Till we meet again. Keep coding. A toast for all your errors which are actually successes.
I find ERROR_SUCCESS quite funny :)
ReplyDeleteAutomatic garbage collection is a feature missing in C and C++. You can't blame WinAPI for this.
There is no DEERP_CATCH when using stdlib functions. Quote from http://msdn.microsoft.com/en-us/library/windows/desktop/ms682453(v=vs.85).aspx
"A thread in an executable that calls the C run-time library (CRT) should use the _beginthreadex and _endthreadex functions for thread management rather than CreateThread and ExitThread; this requires the use of the multithreaded version of the CRT. If a thread created using CreateThread calls the CRT, the CRT may terminate the process in low-memory conditions."
As for TerminateThread() this function is indeed a last resort for forced thread killing. So when you're simply telling the kernel to wipe out the thread what do you expect?
It's been quite a long time since I wrote a Win32 program, so I've forgotten lot of the caveats.
DeleteI guess this post was written after a lot of frustration and heartache when writing a multithreaded C++ program. Check my post on why I like the new C++ (C++11).