Unexpected behavior of std::bitset in visual studio 2008

I was writing code for generating prime numbers up to 10^9 (one billion) by sieve of Erathosthenes. So I created a class containing a member of type std::bitset<1000000000> and created an instance of the sieve class within the main function (i.e., allocated on the stack).

When I ran the program, it crashed with stack overflow. Since VC in debug mode implements stack overflow checking, the stack trace was not very helpful -- the program crashes within the _chkstk function. But in my simple test program, the only possible cause of stack overflow could be the instance of the sieve class which contains the bitset member. After lowering the sive's limit to 1000, the program worked fine. It was kinda surprising to learn that std::bitset, unlike std::vector, internally uses an array instead of dynamically allocated storage. (I confirmed this conjecture also by reading the source code of in the corresponding header file.)

OODraw align nonsense...

I've been drawing some diagrams and I attempted to align (center vertically) several objects using one object as the reference object that should not be moved. But OODraw does not offer such feature; what it does instead is to align the selected objects using their bounding box as the reference, which is completely useless. A workaround is to "protect" the size and position of the reference object and then invoke the align command... which are few unnecessary extra clicks here and there. Stupid, stupid, stupid program!

Git's way to the thrashcan

I tried to use git-svn and git for a while, only to get fed up with it today and going back to just using subversion. The thing that pissed me off is that I did git rm on wrong files. With subversion, if you do svn revert before commit, the old copy of the file gets restored (and, of course, removal will not be scheduled for commit).

With git, git checkout should, in theory, do the same. Googling about the problem, I found a tip that I should use git reset. However, neither did that restore the accidentally deleted files. Finaly, I experimented a bit and found out that git reset --hard does the trick. Before experimenting, I did, of course, make a backup of the whole repository to another place.

Now, I'm going back to subversion, which is much more intuitive to use. My work is too valuable to be stored in version control system with which I must experiment to achieve even the simplest of operatons. Yes, I found the --hard option in the documentation, but its explanation was so opaque that I wasn't sure whether it would achieve what I wanted.

Next time I'll be wanting to use a DVCS, I'll use Mercurial, as before.

The meaningless school...

Now, midst in the financial crisis, I've gotten interested in how the economy works in general. Like, the stock market, how can perpetual economic growth be sustainable (in the long run it's exponential), etc. I would also like to know about things that are relevant for real life, like loan calculations, nominal and effective interest rates, forms of long-term savings, etc. And I know zilch about these things.

These things should be a part of basic high-school education. But no, we've been (and today's pupils are still being) overloaded with a bunch of meaningless historical and geographical facts that can be looked up in any online or offline encyclopedia. Among other meaningless stuff that is mostly irrelevant for the practical side of living in the modern world.

Currently I'm busy with writing my PhD, but first priorities on my reading list (after having finished the PhD) are introductory books in macroeconomy, capitalism, and game theory.

Win32 threading API anomaly

I like to split my code into a series of simple helper functions. When developing for multithreaded environment, some of these functions have to be called while a certain mutex is held by the current thread. In POSIX, it's easy to test for a weaker condition, namely that the mutex is locked:

assert(pthread_mutex_trylock(&mtx) == EBUSY)

There is no way to check that the current thread holds the mutex. However, if another thread has locked the mutex, one may hope that pthread_mutex_unlock will return EPERM error code (I don't think that the pthread library is obliged to check for every possible error condition).

Take Win32, and the TryEnterCriticalSection function which returns, according to the documentation: "If the critical section is successfully entered or the current thread already owns the critical section, the return value is nonzero. If another thread already owns the critical section, the return value is zero."

Since I actually expect that the current thread already owns the mutex, the "or" clause in the first sentence makes it impossible to implement even the (weaker) sanity check which is possible under POSIX. Kinda shame.