When I say "testcases", I don't mean a unit test, or even a functional test, or any set of instructions to verify the correctness of a program. I'm talking about the reduced example you create when you're debugging a program you already know to be functioning incorrectly. Let me demonstrate.
Today I came across this excellent analogy by a gentleman named "DavidWolfire" describing the initialisation, use and discarding of dynamically-allocated memory in C-like languages.
It has begun: There is no such thing as "an auto"! See, this is why I disagreed with the proposal to add this syntactic sugar.
Last year I "left" Stack Overflow but, as predicted, recently found myself trickling back onto it for the fame and glory. Then, this.
I made a mistake that could have cost my application its stability. Learn from the error of my ways!
Alex Darby writes about "the Stack", referring to both the ISO standard and Bjarne's C++ book and complains that they both evade the concept of a stack or a heap as used for laying-out objects in memory.
While writing my previous post, a question came to mind regarding the use of static members for bounding arrays that are members of the same type.
A piece of supposedly well-written multi-threaded code was giving me a headache the other day. I briefly explore a common(?) pitfall in the use of RAII-driven locking mechanisms.
I was posed a question recently as to why the C++ expression true == true == true compiled successfully. The person asking was sure that equality comparison held no associativity and that the expression was thus too ambiguous to be well-formed.
I was linked earlier on to a presentation entitled "The Dark Side Of C++", written in August 2007 by C expert Felix von Leitner. He attempts to explain C++'s pitfalls and demonstrate why a programmer should choose another language. Though the intention is sound and some good points are made, unfortunately it also contains untruths. Therefore, I shall go through parts of the presentation, debunking its lies.
