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.
I love this business card idea – simple but creative. That and it features a text editor I couldn’t do without :-)
Exciting news! According to a blog post made a couple of days ago, the Raspberry Pi team expects the first boards to be available for purchase before the end of Feb! But a little background, the Raspberry Pi project is the brainchild of Eben Upton, formerly a lecture at Cambridge who set out with a simple goal – to try to reignite British educational system passion for by recapturing the programming frontier spirit of the BBC Micros of old. Seven years later and the boards are ready, compact and bristling with ports and potential.
Despite the original focus, the project has been blessed by a huge amount of interest and I for one am excited to get my hands on a board (or possibly several) to see what I can make them do. The boards have already been shown to run XBMC, Quake3 and have the approximate graphical capabilities of the original XBOX – I can’t wait to see what will happen in the coming weeks.
A rather cheeky 2D rip off (yes, I think that’s justified given the identical art assets) of Minecraft called ‘Crafted’ has popped up on the iOS app store. I’m tempted to give, what appears to be the crossbreed between Minecraft and Terrania, a go, but I don’t really want to reward what amounts to intellectual property theft in my opinion.
I’ve been reading with great interest a recently released approximation of the quantity and deposition of radionuclides from the Fukushima Dai-ichi nuclear power plant accident earlier this year. Recently published on the Atmospheric Chemistry and Physics open discussion forum, the PDF form (entitled “Xenon-133 and caesium-137 releases into the atmosphere from the Fukushima Dai-ichi nuclear power plant: determination of the source term, atmospheric dispersion, and deposition”) is freely available.
The discussion paper raises a number of interesting points, particularly the indications of pre-tsunami reactor containment failure as evidenced by radioxenon releases, the large contribution to overall emissions from the spent fuel pool fire (reactor building #4) and the upward rating on the overall estimated radionuclide emissions. I strongly recommend a read.
Photo credit: TEPCO