Porting Visual C++ Code to Visual Studio 2005

Porting Visual C++ Code to Visual Studio 2005

our months ago, Microsoft publicized a list of features that could cause existing Visual C++ apps to break when migrated to Visual Studio 2005. Many of these features are core C++ updates that are meant to bring Visual C++ to full compliance with ISO C++. There’s no doubt that these changes are a major improvement over the non-compliant hacks that have been in use since the mid-1990s. The downside is that migrating to Visual Studio 2005 requires a thorough code review?and possibly some repairs. The following sections show some of the code changes required for porting existing C++ apps to Visual Studio 2005.

Your Visual C++ 6.0 apps will not compile when migrated to Visual Studio 2005 unless you fix them. How do you go about it?

Use this check list to locate incompliant code spots and repair them according the following guidelines.

Code Review and Analysis
Earlier versions of Visual C++ literally forced you to write non-compliant C++ code. Therefore, it’s unlikely that an existing Visual 6.0 app will compile as-is with Visual C++ 8.0 (the C++ compiler of Visual Studio 2005). Therefore, your first step is to review the code and locate potential problems. Before you make any changes to the code, my advice is to review the entire code base and systematically mark all code sections that might be incompatible with Visual Studio 2005. Only then should you make the necessary repairs. It’s better to repair incompliant code in several passes, each dealing with a different category of fixes. For example, your first pass may focus on for-loops, the next pass on exception handling, and so on. There are three reasons for splitting the code repairs to separate sessions:

  • Team Work: Developers specializing in different categories can work on the same code simultaneously.
  • Coding Standards: It’s easier to enforce a uniform coding standard when focusing on one feature at a time.
  • Keyword-based Lookup: Each category is typically associated with a specific C++ keyword (e.g., to locate all for-loops, search for the keyword for).

Code Fixing
Some of the necessary code fixes are rather straightforward. These include for-loops, pointers to member functions, the deprecated “default to int” rule, and exception handling. Let’s see what these all mean.

  • for-loops: In pre-standard C++, variables declared in a for-loop were visible from the loop’s enclosing scope. This behavior is still maintained in Visual C++ 6.0:
    for (int i=0; i

    However, in Visual Studio 2005, the scope of i is restricted to the for-loop. If you want to refer to this variable from the enclosing scope, move its declaration outside the for-loop:

    int i=0;for (; i
  • Figure 1. Exception Handling: This image shows how to override the default exception handling command line flag.
  • Declarations of pointers to members: In pre-standard C++, it was possible to take the address of a member function without using the & operator:
    struct S{ void func();};void (S::*pmf)() = S::func; //allowed in VC++ 6.0

    In Visual Studio 2005, the & is mandatory:

    void (S::*pmf)() = &S::func; //OK

    Tip: To locate problematic code, search for the tokens ::* and ::.

  • "default to int": Pre-standard C++ (and all C variants predating C99), use the "default to int" rule when declarations of functions and variables do not contain an explicit datatype. This behavior is maintained in Visual C++ 6.0 as the following declarations show:
    const x=0; //implicit intstatic num; // implicit intmyfunc(void *ptr); //implicit return type int

    In Visual Studio 2005, you have to specify the datatype explicitly:

    const int x=0; static int num; int myfunc(void *ptr);  

    Tip: To locate incompliant code of this category, compile your app with Visual Studio 2005 and look for compilation errors about a missing datatype in a declaration.

  • Exception Handling: Older versions of Visual C++ happily mixed standard C++ exceptions with the asynchronous Structured Exception Handling (SEH). Consequently, a catch(...) block might catch not just a C++ exception created by a throw statement, but also an asynchronous SEH e.g., access violation. Not only is this behavior incompliant, it makes debugging more difficult. Visual Studio 2005 fixes this loophole. It's now possible to specify whether a catch(...) handler should catch only C++ exceptions by using the default /EHsc flag (this is the recommended option), or maintain the non-standard behavior of Visual C++ 6.0 by using the /EHa flag (see Figure 1).
Author's Note: The fixes shown here don't reflect all of the changes in Visual Studio 2005. For a complete list, consult Visual Studio 2005 homepage. Also, I have focused on core C++ features. Other Visual C++-specific changes such as multithreaded CRTs, deprecated APIs etc., aren't discussed here.

Just in the Nick of Time
Visual Studio 2005 and Visual C++ 6.0 have different Application Binary Interfaces, or ABIs. This means that the same datatype or function may have different binary layouts and mangled names. The different ABIs affect among other things the std::time_t and wchar_t datatypes.

Visual C++ 6.0 treats std::time_t as a 32-bit integer, whereas in Visual Studio 2005 this type is a 64-bit integer. This change might necessitate code updates if your app assumes a 32-bit time_t e.g., hard-coded buffer sizes and format flags (further information on migrating to 64-bit code is available here). Another ABI change affects the representation of the wchar_t type. Up until now, wchar_t has been a typedef synonymous with unsigned short. However, Visual Studio 2005 treats wchar_t as a built-in type. This change might affect the overload resolution of functions:

int _wtolowers(unsigned short *ws);wchar_t ws[10] = L"Test";_wtolowers(ws); 

This code compiles with Visual Studio 6.0 but it will break with Visual Studio 2005 because wchar_t * is incompatible with unsigned short *.

All and Sundry
The changes described here affect not just Visual C++ 6.0 code ported to Visual Studio 2005. Rather, they apply to legacy C++ code ported to an ISO compliant C++ compiler in general. The fear from these changes has led many project managers to defer upgrades at all costs. This policy isn't justified, though. Almost without exception, these changes are only for the best.


Share the Post:

©2023 Copyright DevX - All Rights Reserved. Registration or use of this site constitutes acceptance of our Terms of Service and Privacy Policy.

SitemapPrivacy Policy