I used to use all the beta Microsoft products, now I find it more efficient to move up when I’m ready – and when things have matured. However, a look at the boost regression tests shows that VC7.1 support is getting a bit lean, at least for the serialization library I use. So… time to move on up. Here is how the upgrade from 7.1 to 8.0 went for my HangTheDJ project…


  • First, vc8 installation. No problems.
  • Downloaded latest Platform SDK, installed no problems.
  • Wiped out boost and grabbed a fresh snapshot from cvs.
  • Built boost for vc8.0, no problems.
  • Added boost library path to Visual Studio Tools->Options->Projects and Solutions->VC++ directories
  • Opened my HangTheDJ project and let Visual Studio convert it “in-place”.
  • Added _CRT_SECURE_NO_DEPRECATE to Project->Properties->Config->C++->Preprocesor definitions. Otherwise Microsoft prevents use of “unsafe” functions like strncpy. There are better ways but I’m not rewriting all my legacy code just right this moment. Besides, my code is generally fine, it’s boost and other shared code that more often plays it loose. USE A STRING CLASS, PEOPLE! :>
  • More recently, I updated Visual Studio with SP1. Unfortunately I ran out of hard drive space in the middle and it made sort of a mess of things. Finally reinstalled/repaired enough times to make it happy. It can take a long time. Most annoyingly, make sure you have a couple GB of space on C:\, even if you’re not installing there, to keep the installation happy.


  • 27 errors, 2 warnings, not bad…
  • Looks like Microsoft finally got for loop variable scoping correct – if defined in the for statement, the variable is now scoped inside the braces. So fix any related sloppy coding.
  • The pow() function has new overloads, have to specify types correctly.
  • Slightly stronger type checking – e.g., a time_t is not an int.
  • Default behavior bad. “C++ does not support default-int” – anymore! Fix any crufty code that made the assumption.
  • Some macros (like ON_WM_NCHITTEST) were updated to provide the “correct” (signed) return type, breaking a lot of (often wizard-generated) code. This is the only upgrade hiccup of any significance, and it’s really trivial (albeit annoying) to fix. Explanation is here.
  • HangTheDJ – 0 error(s), 0 warning(s). Upwards and onwards.


  • The actual code generated by VC8 is stricter. I ran into the _SCL_SECURE_VALIDATE_RANGE macro, which asserted when I decremented an iterator below the start of a vector. Why is that a crime? Oh well, I rewrote the code to avoid going outside of the vector range, and everything is humming along now.
  • Lots more debugger checking, and it seems sane for the most part. I found one place where I actually referenced an iterator below the legal boundary, whoops. Fixed. Nice.
  • VC8 is stricter about successfully dynamic_cast’ing. The standard way of dealing with slider control changes is to process OnHScroll() messages in the parent dialog. You get a pointer to a CScrollBar, which is crap, since it actually points to a CSliderCtrl class. Now for the VC8 change: a dynamic_cast<> will FAIL if you don’t static cast to CSliderCtrl* BEFORE trying to dynamic_cast to a CSliderCtrl-derived class. Funny, M$’s improved compiler is exposing the crappiness of their original design. Code should look something like this:
    ListDataByteSlider* pSlider = dynamic_cast< ListDataByteSlider* > ( (CSliderCtrl*)pScrollBar );
    if ( pSlider )
    (it’s a message for your slider, do what you need to do…)


The most tweakable IU yet, the only real complaint is the amount of time to get it just right.

  • The new Ctrl-Tab “NextDocumentWindowNav” behavior (which gives you a temporary list of all files, right in the middle of the screen) is obnoxious and distracting, IMHO. Revert to the more-standard behavior of actually switching to the next file by reassigning the Ctrl-Tab keystroke (and Ctrl-Shift-Tab, of course) from Window.NextDocumentWindowNav to Window.NextDocumentWindow.

Having fun with it now. Microsoft has definitely been improving its compiler.

Leave a Reply