For about six months, I managed to stick to a bi-weekly update schedule of Mondays and Fridays. However, I’ve exhausted my entire backlog of topics, as well as my todo list for things to write about. Instead of trying to force myself to write about something random purely due to an arbitrary schedule, I’m scaling back. Now I’m going to post whenever I have something of value to contribute to the world.
Unfortunately, the only thing of value I have to post about today is the fact that I have nothing of value to post about. ;-) But I do have a lot of random things to mention.
If you’re debugging code in WinDbg, you’ve probably used the !teb command to get access to the thread execution block. I usually use it as a dorky way to see what GetLastError would return. I found myself needed to know what the last error code was today, and I was debugging in Visual Studio. If you find yourself in that situation, the @err command will get that information. If you want the entire TEB, you can get the address of it by doing (struct _TEB *)@tib.
Speaking of Visual Studio, I’ve been teaching myself more about the source annotation language (SAL) that Microsoft supports in C++. I’ve used it in the past, and I’ve certainly made use of the /analyze switch. If you’re interested in learning more about SAL, I’d recommend reading what appears to be the de facto blog posting on the topic. But in this case, I wanted to know how the annotations find their way into the compiler. It turns out there are two different models for annotations. The older one uses __declspec’s to attach the information to the declarations. The newer one uses attributes, which sent me spiraling down a black hole on MSDN. I had no idea that there was a C++ (non-CLI!) implementation of attributes in MSVC. It turns out there is, but it’s entirely undocumented. It is getting a bit more use in Win8 with the WinRT framework, but there’s no way for you to get information about attributes at runtime, even with RTTI. Given the nature of C++ to be as close to the metal as possible, this makes sense. Otherwise the object model would have to carry the data in some form or fashion, and I can imagine that being awkward. So the upside is that I learned something new about MSVC++, and the downside is that I learned absolutely nothing about it at the same time. There’s an obvious structure to creating an attribute, but I’ve yet to fully discern how it works.
While researching attributes, I somehow was lead to the page on compiler intrinsics and found out about __assume. While I don’t have to write incredibly performant code for my day job, I do like to have a good handle on optimizations. This is one I’ve filed away for “huh, I may use this some day.” The basic idea behind it is that you are telling the compiler that it can make an assumption about an expression. A special case of this is the __assume(0) intrinsic which indicates a code path that’s unreachable. In my own code, I tend to have a macro-enabled statement for unreachable code paths which is typically an assert. But now I can use more macro fun to tell the optimizer that I expect the code path to be unreachable in release mode as well! Something along the lines of:
#ifdef _DEBUG #define unreachable_code(msg) assert(false, msg) #else #define unreachable_code(msg) __assume(0) #endif
I’m sure there are other tidbits of things I’ve learned this week, but they escape me at the moment. However, if there are things you’d like me to take a stab at explaining, I’d be happy to give it a shot!
Pingback: Tomato Blog