Among many other fixes coming in the new version of Visual Studio, is a fix to std::to_string (introduced in Visual Studio 2010) providing the full range of numerical types. Currently using the function with any numerical type other than long long or long double or unsigned long long yields compiler error C2668 – ambiguous call to overloaded function.
Whilst annoying, there’s a trivial workaround for Visual Studio 2010 to still use this handy function without resorting to boost::lexical_cast by static_casting to one of the three currently provided overloads. As of VS 2012, such massaging of types is no longer required. 🙂
A few days ago I came across a bit of nasty behaviour when evaluating an expression performing a simple calculation on a signed and unsigned integer. Take the following C++ code snippet:
unsigned int nA = 10;
int nB = 11;
if( nA – nB < 0 )
On first inspection, given the inputs I would expect the expression to evaluate to true. What surprised me is that, despite no compiler warnings being emitted using Visual Studio 2010 at warning level 4, the statement evaluates to false.
It turns out the signed int is silently promoted to an unsigned int which changes things. The answer to 10 – 11 is no longer -1 but 4294967294 ( or UINT_MAX-1 ) since an unsigned integer can’t hold a negative number (no ‘spare’, top bit for sign indication) and has wrapped around.
There are a few different fixes depending on the what your function is trying to do. Assuming mixing signed and unsigned types is unavoidable, the following fix to this is simple assuming there can be no range violations and you won’t end up with a large negative number for the left hand side:
if( static_cast( nA ) – nB < 0 )
I understand that gcc does emit a warning about this with
-Wextra but the usual advice of test test test is hard to beat. Did I mention that I’m a huge fan of unit tests?
I have had a chance to do some power draw monitoring of my Raspberry Pi and to compare with other low power ARM devices devices such as the SheevaPlug. The Raspberry Pi is really hard to beat – pulling roughly 2.0w when idle (with nothing plugged in to the USB or A/V outputs) to 3.2-3.3w at load (with HDMI output and USB keyboard and mouse) when using a standard Amazon Kindle charger as the power source. Something I’ve not had a moment to try is decoding HD video as I’d imagine that would load both the CPU and GPU but I can’t see the load being much higher given the combined CPU and GPU part (I’ll update this post when I confirm this).
Contrast these figures against 4.0w idle to 4.9-5.2w load for the SheevaPlug (also without any USB attachments). Admittedly the SheevaPlug has a slightly faster (1.2Ghz vs 700Mhz) ARM processor than the Raspberry Pi, but it also lacks the RCA/HDMI video output circuitry and has a wonky integrated PSU.
Probably the biggest difference between power consumption of the two devices will be related to power supply efficiency. As I already mentioned, the SheevaPlugs are renowned for being let down by cheap and inadequate integrated power supplies. In fact, I’m on my second Plug for that very reason. Since there is no (easy) way to test both devices with the same power supply, any comparison should probably be taken with a grain of salt.
I came across a great video showing the Portal 2 in-game level editor which is being released soon as part of the Perpetual Testing Initiative DLC. Whilst I was intending on embedding it in this post, it seems the video has been mysteriously pulled from YouTube. For now the following image will have to suffice – I’ll update this post when I find a working video link.
Having seen a demonstration of what can be done, I’m extremely impressed by the clean interface that couples simple geometry manipulation with WYSIWYG design. In the past I have made levels using a number of tools including Deathmatch Maker, QuARK (for the original Quake) to the first version of Hammer for the original Half Life engine. But irrespective of the tool used the basic principles for map creation were the same, as was typically the (rather steep) learning curve. The beauty of this Test Chamber Editor is the player doesn’t have to understand the theory behind binary space partitioning nor worry about leaks or striking the right lighting balance. They simply choose from prefabs of the small number of elements that make up Portal test cambers and see where their imagination takes them. Without trying the editor myself I can’t say much more; but from the video, it looks like a lot of fun.
So my Raspberry Pi finally arrived today! Despite the launch morning kerfuffle I somehow (it’s still a mystery to me exactly how) managed to bag one from the first batch.
Here it is pictured alongside an Arduino for size reference – it’s slightly bigger but not by much. When I’ve had time to really explore what it is capable of I’ll write some more on the subject.