I just found this while debugging an issue:
if ( isConfigured() )
if ( isAllowed() )
I can’t tell you how many times I looked at that before I saw where the problem was. My brain was so used to following styling hints to see control of flow that it didn’t notice that the actual true flow was different from the visual flow. @*&^!
As with most other kids in the 1980s I grew up programming in BASIC. Variables weren’t strongly typed they just held values. Type mismatches were reported at runtime with the ‘Type mismatch at line xx’ error. If you wanted to start running a different piece of code you could simply GOTO whatever line you wanted. BASIC was a great language to learn programming in, you were in charge and the computer did the best to keep up.
Pascal on the other hand was something quite different. Pascal didn’t just run (at least the version we used didn’t), it needed to be compiled first. Variables needed to be declared ahead of time with their type specified before you even used them! No longer could you just jump around the code, instead you had to split the program up into functions and carefully control how they interacted. I hated Pascal. I preferred 6502 assembly (with an instruction set so limited there was no multiply operator) to Pascal.
I spend a lot of time moving between C++ and C#. Fortunately the languages are different enough that it’s not too difficult switching between using concepts such as stack allocated objects in C++ and garbage collected objects in C#. However, if I’m not concentrating I do run into trouble when coding in Managed C++ since I expect it to generally behave just like C++, just with access to .NET classes.
Managed C++ is really cool but it has a couple of gotchas. The one that has bitten me more than once is the difference between destructors and finalizers. To make sure that I don’t fall into the trap again I’m going to elaborate on what is a very long comment in one of our source code files.
In standard C++ you would write something like:
I’m currently in the process of moving all our source over to Visual Studio 2008. Most of our 3rd party libraries compiled right out of the box. However, the excellent Boost library was not so simple.
Boost has quite a complex build process that automatically discovers your compiler and builds the library with almost no user interaction. Unfortunately the current release of Boost (1.34) does not recognize VS2008 and the build process will only pick up older versions of the compiler. Fortunately once you know what files need to change it’s not too difficult to add a new compiler to the build process.
For anyone else who’s trying to compile Boost with VS2008 the link below contains the files I updated to fix our build process.