Hey everyone,
I just wanted to write up a quick post to apologize for the funky formatting of code in the last post. I’m currently trying to figure out the best way to get code to look right inside of wordpress, without the WYSWYG editor fubaring it. As I work out the best way to format code I’ll be going back to fix older posts, and I hope that you’ll stick with us through this refinement stage of the site.
A common development problem, and one that is becoming even more important as processors gain more cores, and computers themselves gain more processors, is the issue of concurrency. Dealing with concurrency, that is to say multithreaded programming, is vitally important for obtaining top level performance on modern systems. Even in cases where performance isn’t critical, multithreaded programming (especially for GUIs) can vastly improve the user experience of an application. In this part 1 of a series on concurrent programming with C++, I examine what makes using pthreads with C++ difficult at times, and suggest two methods for easily integrating pthreads with an Object-Oriented C++ application, along with an in-depth look at pointer-to-member function syntax and in the light of this practical application.
$70,000,000(USD) – Seventy Million Dollars, an absolutely meaningless estimate of the cost of an average mid-sized in-house enterprise business application. I say meaningless here for two primary reasons. The first is that this number has almost no relation to the actual cost that an average company would spend to create the software, and second because it has absolutely no relation to what an average business would by or could sell the software for. So where does this perfectly meaningless number come from? It is an estimate based off of one of the mostly ill-conceived metrics in use in the software industry today, Lines of Code (LoC). There is an interesting insidiousness to the measurement, it’s one that everyone seems to recognize as inherently flawed, and yet it’s popularity never seems to waver. In order to really address this issue we need to first understand why Lines of Code is such an ineffective metric for measuring a codebase; once we understand why it’s so bad, it is necessary to look at why we keep using it- what information do we hope to convey by using this metric, and finally, what other terms and metrics might be useful in conveying this information, without the pitfalls of the Lines of Code measurement.